All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Emil Tsalapatis" <emil@etsalapatis.com>, bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next v5 6/9] selftests/bpf: libarena: Handle NMI reentrancy
Date: Tue, 10 Nov 2026 01:34:54 +0000	[thread overview]
Message-ID: <sashiko-outbox-205971@kernel.org> (raw)
In-Reply-To: <20261110003838.8739-7-emil@etsalapatis.com>

Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Low] selftests/bpf: inconsistent error return in
  buddy_deferred_free_start_bulk()
--

commit 6751ae768506dfa7101c71c63c2aa51a0d3eb6cc
Author: Emil Tsalapatis <emil@etsalapatis.com>

selftests/bpf: libarena: Handle NMI reentrancy

This commit handles NMI reentrancy in the libarena buddy allocator by using
a trylock in NMI context and deferring frees onto an intrusive lockless list
when the buddy lock cannot be acquired.

> diff --git a/tools/testing/selftests/bpf/libarena/src/buddy.bpf.c b/tools/testing/selftests/bpf/libarena/src/buddy.bpf.c
> index 58e666210fdbd..7fd74f4c50526 100644
> --- a/tools/testing/selftests/bpf/libarena/src/buddy.bpf.c
> +++ b/tools/testing/selftests/bpf/libarena/src/buddy.bpf.c

[ ... ]

> @@ -1187,6 +1201,98 @@ static __always_inline int buddy_free_unlocked(struct buddy __arena *buddy, u64
>  	return 0;
>  }
>  
> +static bool buddy_deferred_free_pending(struct buddy __arena *buddy)
> +{
> +	return buddy->deferred_free != NULL;
> +}

[ ... ]

> +static int buddy_deferred_free_start_bulk(struct buddy __arena *buddy,
> +		 void __arena * __arena *addrs, size_t naddrs)
> +{
> +	void __arena *first, *last, *addr;
> +	unsigned int i;
> +	int ret = 0, order;
> +
> +	/*
> +	 * Chain the allocations into a local linked list. Possible because
> +	 * allocations are 16 bytes minimum and so fit a pointer.
> +	 */
> +	first = NULL;
> +	last = NULL;
> +	for (i = zero; i < naddrs && can_loop; i++) {
> +		addr = addrs[i];
> +		if (!addr)
> +			continue;
> +
> +		order = buddy_cache_get_order(addr);
> +		if (order >= BUDDY_CHUNK_NUM_ORDERS) {
> +			ret = -EINVAL;
> +			continue;
> +		}
> +
> +		asan_poison(addr, BUDDY_POISONED, BUDDY_MIN_ALLOC_BYTES << order);
> +		asan_unpoison(addr, sizeof(void *));
> +
> +		if (!first)
> +			first = addr;
> +		else
> +			*(void __arena * __arena *)last = addr;
> +
> +		last = addr;
> +	}
> +
> +	if (!first)
> +		return ret;
> +
> +	/* Splice the local list onto the deferred-free list. */
> +	buddy_deferred_free_push(buddy, first, last);
> +	return 0;
> +}

[Severity: Low]
Is the return value of buddy_deferred_free_start_bulk() intended when an
address in addrs[] has an invalid order?

When a batch contains both an invalid address and at least one valid
address, the final "return 0" discards the "ret = -EINVAL" recorded in the
loop.  Conversely, when every non-NULL address in the batch is invalid,
"!first" is true and this returns -EINVAL, whereas the locked path in
buddy_free_bulk() returns 0 and leaves invalid-object reporting to
buddy_free_unlocked() (which is also skipped for addresses filtered out
here).

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261110003838.8739-1-emil@etsalapatis.com?part=6

  reply	other threads:[~2026-11-10  1:34 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-10  0:38 [PATCH bpf-next v5 0/9] bpf libarena allocator improvements Emil Tsalapatis
2026-11-10  0:38 ` [PATCH bpf-next v5 1/9] selftests/bpf: libarena: Add bulk buddy allocation helpers Emil Tsalapatis
2026-11-10  0:38 ` [PATCH bpf-next v5 2/9] selftests/bpf: Add a parallel buddy allocator benchmark Emil Tsalapatis
2026-11-10  4:51   ` bot+bpf-ci
2026-11-10  0:38 ` [PATCH bpf-next v5 3/9] selftests/bpf: libarena: Make spinlock trylock match arena_spin_unlock Emil Tsalapatis
2026-11-10  0:38 ` [PATCH bpf-next v5 4/9] selftests/bpf: libarena: Raise arena spinlock CPU limits Emil Tsalapatis
2026-11-10  0:38 ` [PATCH bpf-next v5 5/9] selftests/bpf: libarena: Add buddy per-CPU caches Emil Tsalapatis
2026-11-10  0:38 ` [PATCH bpf-next v5 6/9] selftests/bpf: libarena: Handle NMI reentrancy Emil Tsalapatis
2026-11-10  1:34   ` sashiko-bot [this message]
2026-11-10  4:51   ` bot+bpf-ci
2026-11-10  0:38 ` [PATCH bpf-next v5 7/9] selftests/bpf: libarena: Refill local caches in batches Emil Tsalapatis
2026-11-10  4:51   ` bot+bpf-ci
2026-11-10  0:38 ` [PATCH bpf-next v5 8/9] selftests/bpf: libarena: Add a transfer cache Emil Tsalapatis
2026-11-10  0:38 ` [PATCH bpf-next v5 9/9] selftests/bpf: libarena: Cover buddy cache fast paths Emil Tsalapatis
2026-11-12 21:00 ` [PATCH bpf-next v5 0/9] bpf libarena allocator improvements patchwork-bot+netdevbpf

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=sashiko-outbox-205971@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=emil@etsalapatis.com \
    --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.