Re: [PATCH bpf-next v7 0/9] Introduce arena library and runtime

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

On Fri Apr 17, 2026 at 12:15 PM EDT, Kumar Kartikeya Dwivedi wrote:
> On Fri, 17 Apr 2026 at 15:43, Emil Tsalapatis <emil@etsalapatis.com> wrote:
>>
>> On Sun Apr 12, 2026 at 3:22 PM EDT, Kumar Kartikeya Dwivedi wrote:
>> > On Sun, 12 Apr 2026 at 19:45, Emil Tsalapatis <emil@etsalapatis.com> wrote:
>> >>
>> >> Add a new subdirectory to tools/testing/selftests/bpf called libarena,
>> >> along with programs useful for writing arena-based BPF code. This
>> >> patchset adds the following:
>> >>
>> >> 1) libarena, a subdirectory where arena BPF code that is generally useful
>> >> to BPF arena programs can be easily added and tested.
>> >>
>> >> 2) An ASAN runtime for BPF arena programs. BPF arenas allow for accessing
>> >> memory after it has been freed or if it is out of bounds, making it more
>> >> difficult to triage bugs combined to regular BPF. Use LLVM's recently added
>> >> support for address-space based sanitization to selectively sanitize just
>> >> the arena accesses.
>> >>
>> >> 3) A buddy memory allocator that can be reused by BPF programs to handle
>> >> memory allocation/deletion. The allocator uses the ASAN runtime to add
>> >> address sanitization if requested.
>> >>
>> >> The patch includes testing for the new allocators and ASAN features that
>> >> can be built from the top directory using "make libarena_test" and
>> >> "make libarena_test_asan". The generated binaries reside in libarena/.
>> >> The patch also adds test-progs-based selftests to the codebase for the
>> >> libarena code, so the new tests are run by ./test_progs.
>> >>
>> >
>> > I am back in the same position as I was with comments in [0].
>> >
>> > I.e., again, I don't see anything in the stream output (passing -v to
>> > test_libarena_asan) when I build it with clang 23 (LLVM tip).
>> > What am I doing wrong? (Leaving aside all feedback about integrating
>> > it in the regular test runner that is still unaddressed, thus tests do
>> > not run by default).
>> >
>> >   [0]: https://lore.kernel.org/bpf/CAP01T75+BoQfQN=47NhYYviZttjCPb_CXNpa=DUC0=xSvdNZdA@mail.gmail.com
>>
>> The series introduces a selftest for the test runner called libarena. It
>> is introduced in patch 9 to avoid creating a runner that does nothing in
>> the previous patches. Tests run with test_progs like regular selftests.
>> For ASAN we do not have LLVM22 support in the CI yet so test_progs doesn't
>> exercise it.
>>
>> The stream output is suppressed by a switch in asan.c to make the output
>> of test_libarena_asan legible. Each test that expects to generate ASAN
>> will generate a ton of output. I will add userspace logic to consume
>> the splats instead of emitting them to keep the output sane.
>
> Why can't we put everything in test_progs instead of separate test_libarena?
> Then add some logic like existing stream tests for verifying / testing
> the generated output in ASAN mode.
> For example, libbpf doesn't have its own separate test suite. I think the same
> logic should apply to libarena.
>

libarena is different in that it's BPF code we distribute as source. 
Plus, the test runner is an example of how to set up the arena state.
It's very little code and automatically identifies the selftests without
having to explicitly enumerate them, so it's not extra maintenance burden.
For followup patches it's been 0 LOC to either the libarena selftest or the
test_progs test.

> If LLVM 22 is a problem just detect and mark the test as skipped for
> now when unavailable.
>

Fair enough we can make it in the Makefile to check if the ASAN flag is
supported by the BPF backend before compiling the selftest, otherwise
make it a no-op.

>>
>> >
>> >> [...]
>>