All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Jiayuan Chen" <jiayuan.chen@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 06:23:32 +0000	[thread overview]
Message-ID: <20260728062332.806161F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260728060517.95183-1-jiayuan.chen@linux.dev>

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?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260728060517.95183-1-jiayuan.chen@linux.dev?part=1

  reply	other threads:[~2026-07-28  6:23 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 [this message]
2026-07-28  6:32   ` Jiayuan Chen

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=20260728062332.806161F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=jiayuan.chen@linux.dev \
    --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.