Re: [PATCH bpf-next v8 6/8] selftests/bpf: Add buddy allocator for libarena

["Emil Tsalapatis" <emil@etsalapatis.com>]

On Tue Apr 21, 2026 at 1:52 PM EDT, bot+bpf-ci wrote:
>> diff --git a/tools/testing/selftests/bpf/libarena/include/buddy.h b/tools/testing/selftests/bpf/libarena/include/buddy.h
>> new file mode 100644
>> index 000000000000..00e2437128ef
>> --- /dev/null
>> +++ b/tools/testing/selftests/bpf/libarena/include/buddy.h
>> @@ -0,0 +1,92 @@
>
> [ ... ]
>
>> +struct buddy_header {
>> +	u32 prev_index;	/* "Pointer" to the previous available allocation of the same size. */
>> +	u32 next_index; /* Same for the next allocation. */
>> +};
>
> In v4, Alexei Starovoitov asked for a mathematical analysis of the
> memory savings from using indices instead of pointers here:
>
> https://lore.kernel.org/bpf/CAADnVQKnHXg0YnuLvzfXjszMaqugpMNWD5=ipffWS4GVNg6rFQ@mail.gmail.com/
>
> The question was: "BUDDY_CHUNK_ITEMS is used like NULL? The header is
> u32 + u32. Is it really worth saving 8 bytes? Use two proper pointers?
> How many headers are there? ... if everything is a pointer the whole
> algorithm would be so much easier to understand. Is it worth it to keep
> indices vs pointers? Please do the math and explain the savings."
>
> The rationale provided in the discussion focused on ASAN effectiveness
> and memory corruption detection, but didn't include the mathematical
> analysis of memory savings that was explicitly requested. Would it be
> helpful to document the quantitative analysis in the commit message or
> code comments to address the original question?

No, this was resolved during discussion of the earlier version. Using
pointers would mean storing the header at the very beginning of a 16
byte block and as a result defeat ASAN.

>
> [ ... ]
>
>
> ---
> AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
> See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
>
> CI run summary: https://github.com/kernel-patches/bpf/actions/runs/24736048353