From: Jiayuan Chen <jiayuan.chen@linux.dev>
To: Kumar Kartikeya Dwivedi <memxor@gmail.com>, bpf@vger.kernel.org
Cc: Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>,
Eduard Zingerman <eddyz87@gmail.com>,
Martin KaFai Lau <martin.lau@linux.dev>,
Song Liu <song@kernel.org>,
Yonghong Song <yonghong.song@linux.dev>,
Jiri Olsa <jolsa@kernel.org>,
Emil Tsalapatis <emil@etsalapatis.com>,
Puranjay Mohan <puranjay@kernel.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH bpf-next] bpf: arena: fix mmap_lock deadlock on arena lock failure
Date: Mon, 3 Aug 2026 09:35:49 +0800 [thread overview]
Message-ID: <adeafc32-65cd-43f7-9e7d-cfcd6ef86327@linux.dev> (raw)
In-Reply-To: <DKEWY0MJHZ64.ALDUTQQ1RPLG@gmail.com>
On 8/3/26 9:21 AM, Kumar Kartikeya Dwivedi wrote:
> On Tue Jul 28, 2026 at 8:05 AM CEST, Jiayuan Chen wrote:
>> Reported by the Sashiko AI review.
>>
>> arena_vm_fault() returns VM_FAULT_RETRY when it can't take
>> arena->spinlock, but it never took mmap_lock. The fault path assumes a
>> VM_FAULT_RETRY handler already dropped mmap_lock and re-takes it on the
>> retry, so mmap_lock gets taken twice and can deadlock:
>>
>> do_user_addr_fault()
>> {
>> fault = handle_mm_fault(...); // calls arena_vm_fault()
>> if (fault & VM_FAULT_RETRY)
>> goto retry; // re-locks mmap_lock
>> mmap_read_unlock(mm);
>> }
>>
>> Return VM_FAULT_SIGBUS instead, for two reasons:
>>
>> 1. We could keep VM_FAULT_RETRY, but then we'd have to drop the fault
>> lock first and cap the retry ourselves, the way __folio_lock_or_retry()
>> does.
>>
>> 2. A failed raw_res_spin_lock_irqsave() already means a possible deadlock
>> was detected, so retrying just hits the same lock again.
>>
>> So returning VM_FAULT_RETRY here is overkill.
>>
>> Fixes: b8467290edab ("bpf: arena: make arena kfuncs any context safe")
>> Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
>>
>> ---
>> target to bpf-next since I think it is moderate.
>> ---
> This looks ok to me, but after staring at this function for longer, I think all
> kinds of non-recoverable errors should be using VM_FAULT_SIGBUS vs SIGSEGV.
>
> The only case with SIGSEGV should be the flag based request to disable
> allocation on lazy faults. That should include the scratch page case, since it
> represents a hole.
>
> SIGSEGV: BPF_F_SEGV_ON_FAULT, scratch page.
> SIGBUS: lock acquisition failure, range-tree failures, page allocation failure,
> kernel PTE install failure.
>
> All of these SIGBUS are almost improbable, but I think it would be cleaner to
> keep semantics clear.
>
> Could you follow up with this change? I applied this one for now.
Sure. I'm happy to do it.
>> kernel/bpf/arena.c | 8 ++++++--
>> 1 file changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/kernel/bpf/arena.c b/kernel/bpf/arena.c
>> index 34f023a537fe..555ee2531ef9 100644
>> --- a/kernel/bpf/arena.c
>> +++ b/kernel/bpf/arena.c
>> @@ -490,8 +490,12 @@ static vm_fault_t arena_vm_fault(struct vm_fault *vmf)
>> kaddr = kbase + (u32)(vmf->address);
>>
>> if (raw_res_spin_lock_irqsave(&arena->spinlock, flags))
>> - /* Make a reasonable effort to address impossible case */
>> - return VM_FAULT_RETRY;
>> + /*
>> + * A failed lock means a possible deadlock was detected. Don't
>> + * return VM_FAULT_RETRY: this handler never took mmap_lock, but
>> + * the fault path would re-take it on retry and deadlock. Fail.
>> + */
>> + return VM_FAULT_SIGBUS;
>>
>> page = vmalloc_to_page((void *)kaddr);
>> if (page) {
prev parent reply other threads:[~2026-08-03 1:36 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-28 6:05 [PATCH bpf-next] bpf: arena: fix mmap_lock deadlock on arena lock failure Jiayuan Chen
2026-07-28 6:23 ` sashiko-bot
2026-07-28 6:32 ` Jiayuan Chen
2026-07-29 21:51 ` Emil Tsalapatis
2026-07-29 21:51 ` Emil Tsalapatis
2026-08-03 1:21 ` Kumar Kartikeya Dwivedi
2026-08-03 1:28 ` Kumar Kartikeya Dwivedi
2026-08-03 1:35 ` Jiayuan Chen [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=adeafc32-65cd-43f7-9e7d-cfcd6ef86327@linux.dev \
--to=jiayuan.chen@linux.dev \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=emil@etsalapatis.com \
--cc=jolsa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=martin.lau@linux.dev \
--cc=memxor@gmail.com \
--cc=puranjay@kernel.org \
--cc=song@kernel.org \
--cc=yonghong.song@linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.