All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jiayuan Chen <jiayuan.chen@linux.dev>
To: sashiko-reviews@lists.linux.dev
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next] bpf: arena: fix mmap_lock deadlock on arena lock failure
Date: Tue, 28 Jul 2026 14:32:44 +0800	[thread overview]
Message-ID: <80b2e0fb-ef66-4b3e-9436-9dbcaa022d19@linux.dev> (raw)
In-Reply-To: <20260728062332.806161F000E9@smtp.kernel.org>


On 7/28/26 2:23 PM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
>
> Pre-existing issues:
> - [High] BPF arena page faults can spuriously crash the user process with SIGSEGV due to transient lockless allocation failures.
> --
>
> --- Patch [1]: [PATCH bpf-next] bpf: arena: fix mmap_lock deadlock on arena lock failure ---
> commit c57623f4077e743e8c901306fcec7c67d2aafc17
> Author: Jiayuan Chen <jiayuan.chen@linux.dev>
>
> bpf: arena: fix mmap_lock deadlock on arena lock failure
>
> This commit fixes a potential deadlock in the arena page fault handler by
> returning VM_FAULT_SIGBUS instead of VM_FAULT_RETRY when the arena spinlock
> cannot be acquired. Returning retry would cause the fault path to attempt
> retaking the mmap_lock, which was never dropped.
>
>> diff --git a/kernel/bpf/arena.c b/kernel/bpf/arena.c
>> --- 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;
> [Severity: High]
> This is a pre-existing issue, but looking further down in arena_vm_fault(),
> does a transient allocation failure unexpectedly cause a SIGSEGV?
>
> Since the raw spinlock is held, disabling IRQs, bpf_map_alloc_pages()
> falls back to an opportunistic lockless allocation which can fail under
> memory pressure:
>
> 	ret = bpf_map_alloc_pages(map, NUMA_NO_NODE, 1, &page);
> 	if (ret) {
> 		range_tree_set(&arena->rt, vmf->pgoff, 1);
> 		goto out_sigsegv_memcg;
> 	}
>
> When this lockless allocation fails, the error path jumps to
> out_sigsegv_memcg and returns VM_FAULT_SIGSEGV instead of VM_FAULT_OOM or
> safely dropping the lock to retry.
>
> Could this cause user processes mapping a BPF arena to experience spurious
> crashes during memory contention?


Yes I'm on it 
https://lore.kernel.org/bpf/20260727062521.376231-1-jiayuan.chen@linux.dev/

And current patch is from your review result of that patch...


      reply	other threads:[~2026-07-28  6:33 UTC|newest]

Thread overview: 3+ 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 [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=80b2e0fb-ef66-4b3e-9436-9dbcaa022d19@linux.dev \
    --to=jiayuan.chen@linux.dev \
    --cc=bpf@vger.kernel.org \
    --cc=sashiko-reviews@lists.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.