BPF List
 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 3/4] selftests/bpf: libarena: add explicit buddy_grow() call
Date: Tue, 27 Oct 2026 16:52:21 +0000	[thread overview]
Message-ID: <sashiko-outbox-186960@kernel.org> (raw)
In-Reply-To: <20261027162916.10996-4-emil@etsalapatis.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] selftests/bpf: buddy_grow() treats byte size parameter as 1 MiB chunk count
--

commit 423ea247cbc2154b99ae3fbf8b3a6fc0e7d6e98f
Author: Emil Tsalapatis <emil@etsalapatis.com>

selftests/bpf: libarena: add explicit buddy_grow() call

This commit adds buddy_grow() to libarena to allow BPF programs to
explicitly grow the buddy allocator arena instead of relying on implicit
growth during buddy_alloc().

> diff --git a/tools/testing/selftests/bpf/libarena/include/libarena/buddy.h b/tools/testing/selftests/bpf/libarena/include/libarena/buddy.h
> index 958450fc5f9db..4cad0649dc17a 100644
> --- a/tools/testing/selftests/bpf/libarena/include/libarena/buddy.h
> +++ b/tools/testing/selftests/bpf/libarena/include/libarena/buddy.h
> @@ -78,5 +78,6 @@ int buddy_destroy(struct buddy __arena *buddy);
>  int buddy_free(struct buddy __arena *buddy, void __arena *free);
>  void __arena *buddy_alloc(struct buddy __arena *buddy, size_t size);
>  void __arena *buddy_alloc_nogrow(struct buddy __arena *buddy, size_t size);
> +int buddy_grow(struct buddy __arena *buddy, size_t size);
>  
>  #endif /* __BPF__  */
> diff --git a/tools/testing/selftests/bpf/libarena/src/buddy.bpf.c b/tools/testing/selftests/bpf/libarena/src/buddy.bpf.c
> index ed359d4af1f4b..f06b6bd5c088e 100644
> --- a/tools/testing/selftests/bpf/libarena/src/buddy.bpf.c
> +++ b/tools/testing/selftests/bpf/libarena/src/buddy.bpf.c
> @@ -812,6 +812,32 @@ void __arena *buddy_alloc_nogrow(struct buddy __arena *buddy, size_t size)
>  	return buddy_alloc_maygrow(buddy, size, false);
>  }
>  
> +__weak
> +int buddy_grow(struct buddy __arena *buddy, size_t size)
> +{
> +	struct buddy_chunk __arena  *chunk;
> +	unsigned long flags;
> +	int i;
> +
> +	for (i = zero; i < size && can_loop; i++) {
> +		chunk = buddy_chunk_get(buddy);
> +		if (!chunk)
> +			return -ENOMEM;

[Severity: Medium]
In tools/testing/selftests/bpf/libarena/include/libarena/buddy.h,
buddy_grow() is declared right below buddy_alloc() and
buddy_alloc_nogrow() with the same size_t size parameter, which takes a
size in bytes in those functions.

In tools/testing/selftests/bpf/libarena/src/buddy.bpf.c, buddy_grow() uses
size directly as the loop trip count for buddy_chunk_get(buddy). Each call
to buddy_chunk_get() allocates a 1 MiB chunk (BUDDY_CHUNK_BYTES, or
BUDDY_CHUNK_PAGES = 256 pages) out of the 1 GiB reserved virtual address
range (BUDDY_VADDR_SIZE = 1024 chunks).

If a caller passes a byte count (consistent with buddy_alloc()) or a page
count to buddy_grow(buddy, size), it will allocate size 1 MiB chunks, and
any size greater than 1024 will exhaust BUDDY_VADDR_SIZE and fail with
-ENOMEM while leaving the 1024 allocated chunks attached to
buddy->first_chunk.

Should buddy_grow() convert a byte size into the number of chunks to
allocate, or should the parameter be renamed (for example, to nr_chunks)
and documented to make the unit explicit?

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

  reply	other threads:[~2026-10-27 16:52 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-27 16:29 [PATCH bpf-next 0/4] selftests/bpf: libarena: compatibility fixups Emil Tsalapatis
2026-10-27 16:29 ` [PATCH bpf-next 1/4] libarena: remove in-code licenses Emil Tsalapatis
2026-10-27 16:36   ` sashiko-bot
2026-10-27 16:29 ` [PATCH bpf-next 2/4] selftests/bpf: libarena: make allocator growth on alloc failure optional Emil Tsalapatis
2026-10-27 16:29 ` [PATCH bpf-next 3/4] selftests/bpf: libarena: add explicit buddy_grow() call Emil Tsalapatis
2026-10-27 16:52   ` sashiko-bot [this message]
2026-10-27 16:29 ` [PATCH bpf-next 4/4] selftests/bpf: libarena: Make zero variable type __u32 instead of u32 Emil Tsalapatis

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