From nobody Thu Feb 12 19:06:07 2026 Received: from www262.sakura.ne.jp (www262.sakura.ne.jp [202.181.97.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 99526225AE for ; Sat, 8 Jun 2024 10:54:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=202.181.97.72 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717844048; cv=none; b=drsAG6I5DZwc4ekDZ4Qexy5ria7x8e99hlNXbX7I99SCH3x8HmiMmZFGaGNl+Hp3cUCu7ZcEKcloRqSBdVnHKCFprVBKSILndkmW1nl0uyZRDKqIhmZy0aslX9Q0Gh5f5JjfhW+QXD5tPLrAgFPaFTkD+Fda58BJGzU1OXxJn/k= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717844048; c=relaxed/simple; bh=44DTloEeKsBg4dBlBuyizCM9byVD9CJayt2Jk0ig1Lc=; h=Message-ID:Date:MIME-Version:To:Cc:From:Subject:Content-Type; b=Xbnq+DFlK1ZeIqicJVmWz0KCQ/DrW0FH3AEINu4AR/qgUYcBdenfEMi2HBNx80dxwiJZbDn9GCdOi4dQKttwH3Dm81CiSsMEjTp74P878NcGKBfPt2AV5+xzfi3IYBoO4+ypoMQtfzmdPOoJ8s0onKblM5FChno2vbIw9ovgwUs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=I-love.SAKURA.ne.jp; spf=pass smtp.mailfrom=I-love.SAKURA.ne.jp; arc=none smtp.client-ip=202.181.97.72 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=I-love.SAKURA.ne.jp Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=I-love.SAKURA.ne.jp Received: from fsav312.sakura.ne.jp (fsav312.sakura.ne.jp [153.120.85.143]) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTP id 458ArvJ4026841; Sat, 8 Jun 2024 19:53:57 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) Received: from www262.sakura.ne.jp (202.181.97.72) by fsav312.sakura.ne.jp (F-Secure/fsigk_smtp/550/fsav312.sakura.ne.jp); Sat, 08 Jun 2024 19:53:57 +0900 (JST) X-Virus-Status: clean(F-Secure/fsigk_smtp/550/fsav312.sakura.ne.jp) Received: from [192.168.1.6] (M106072142033.v4.enabler.ne.jp [106.72.142.33]) (authenticated bits=0) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTPSA id 458Arvca026836 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NO); Sat, 8 Jun 2024 19:53:57 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) Message-ID: <4b875158-1aa7-402e-8861-860a493c49cd@I-love.SAKURA.ne.jp> Date: Sat, 8 Jun 2024 19:53:58 +0900 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Eduard Zingerman , Song Liu , Yonghong Song , John Fastabend , KP Singh , Stanislav Fomichev , Hao Luo , Jiri Olsa Cc: bpf , LKML From: Tetsuo Handa Subject: [PATCH] bpf: don't call mmap_read_trylock() from IRQ context Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" syzbot is reporting that the same local lock is held when trying to hold mmap sem from both IRQ enabled context and IRQ context. Since all callers use bpf_mmap_unlock_get_irq_work() before calling mmap_read_trylock(), test in_hardirq() at bpf_mmap_unlock_get_irq_work() in order to make sure that mmap_read_trylock() won't be called from IRQ context. asm_exc_page_fault() =3D> exc_page_fault() =3D> handle_page_fault() =3D> do_user_addr_fault() =3D> handle_mm_fault() =3D> __handle_mm_fault() =3D> handle_pte_fault() =3D> do_pte_missing() =3D> do_anonymous_page() =3D> vmf_anon_prepare() =3D> mmap_read_trylock() =3D> __mmap_lock_trace_start_locking() =3D> __mmap_lock_do_trace_start_locking() =3D> local_lock_acquire() =3D> lock_acquire() sysvec_irq_work() =3D> instr_sysvec_irq_work() =3D> __sysvec_irq_work() =3D> irq_work_run() =3D> irq_work_run_list() =3D> irq_work_single() =3D> do_bpf_send_signal() =3D> group_send_sig_info() =3D> rcu_read_unlock= () =3D> rcu_lock_release() =3D> lock_release() =3D> trace_lock_release() =3D> perf_trace_lock() =3D> perf_trace_run_bpf_submit() =3D> trace_call_b= pf() =3D> bpf_prog_run_array() =3D> bpf_prog_run() =3D> __bpf_prog_run() =3D> bpf_dispatcher_nop_func() =3D> bpf_prog_e6cf5f9c69743609() =3D> __bpf_get_stack() =3D> stack_map_get_build_id_offset() =3D> mmap_read_trylock() =3D> __mmap_lock_trace_acquire_returned() =3D> __mmap_lock_do_trace_acquire_returned() =3D> local_lock_acquire() =3D> lock_acquire() WARNING: inconsistent lock state 6.10.0-rc2-syzkaller-00222-gd30d0e49da71 #0 Not tainted Reported-by: syzbot -------------------------------- inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage. syz-executor.2/10910 [HC1[1]:SC0[0]:HE0:SE1] takes: ffff8880b9538828 (lock#10){?.+.}-{2:2}, at: local_lock_acquire include/linu= x/local_lock_internal.h:29 [inline] ffff8880b9538828 (lock#10){?.+.}-{2:2}, at: __mmap_lock_do_trace_acquire_re= turned+0x8f/0x630 mm/mmap_lock.c:237 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(lock#10); lock(lock#10); *** DEADLOCK *** Reported-by: syzbot Closes: https://syzkaller.appspot.com/bug?extid=3Da225ee3df7e7f9372dbe Signed-off-by: Tetsuo Handa --- Example is https://syzkaller.appspot.com/text?tag=3DCrashReport&x=3D1649a2e= 2980000 . But not using this example, for this link will disappear eventually. kernel/bpf/mmap_unlock_work.h | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/kernel/bpf/mmap_unlock_work.h b/kernel/bpf/mmap_unlock_work.h index 5d18d7d85bef..337eb314d918 100644 --- a/kernel/bpf/mmap_unlock_work.h +++ b/kernel/bpf/mmap_unlock_work.h @@ -26,7 +26,13 @@ static inline bool bpf_mmap_unlock_get_irq_work(struct m= map_unlock_irq_work **wo struct mmap_unlock_irq_work *work =3D NULL; bool irq_work_busy =3D false; =20 - if (irqs_disabled()) { + if (in_hardirq()) { + /* + * IRQ context does not allow to trylock mmap sem. + * Force the fallback code. + */ + irq_work_busy =3D true; + } else if (irqs_disabled()) { if (!IS_ENABLED(CONFIG_PREEMPT_RT)) { work =3D this_cpu_ptr(&mmap_unlock_work); if (irq_work_is_busy(&work->irq_work)) { --=20 2.34.1