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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox