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
next prev parent 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