Re: [PATCH bpf-next 5/5] selftests/bpf: Add arena allocation race tests

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] The selftest fails to load on ARM64 because `flush_tlb_kernel_range` is a static inline function.
- [Medium] Busy-waiting in an fentry BPF program for a userspace thread guarantees a test timeout on UP non-preemptible kernels.
--

commit 03dd0a4c6fda5e1c4877d7ca2aff23509f39c69f
Author: Emil Tsalapatis <emil@etsalapatis.com>
Subject: selftests/bpf: Add arena allocation race tests

This commit adds selftests to handle concurrent accesses to arena
allocations, including sleepable and non-sleepable page allocation
paths, to ensure no inconsistent or lost data occurs.

> diff --git a/tools/testing/selftests/bpf/prog_tests/arena_race.c b/tools/testing/selftests/bpf/prog_tests/arena_race.c
> index 0000000000000..c3a2a4397315a
> --- /dev/null
> +++ b/tools/testing/selftests/bpf/prog_tests/arena_race.c
[ ... ]
> +	/* Force a reallocation during the flush. */
> +	run_prog(skel->progs.try_realloc, "realloc_before_flush");
> +	ASSERT_NULL(skel->bss->realloc_ptr, "realloc_before_flush");
> +
> +release:
> +	skel->bss->release = 1;

[Severity: Medium]
Will this test deterministically timeout or deadlock on uniprocessor systems
when CONFIG_PREEMPT_NONE is set?

The userspace thread needs CPU time to execute this assignment, but the BPF
program may be hogging the only CPU by spinning in wait_for_release().

[ ... ]
> diff --git a/tools/testing/selftests/bpf/progs/arena_race.c b/tools/testing/selftests/bpf/progs/arena_race.c
> index 0000000000000..df5b54ef5b4c0
> --- /dev/null
> +++ b/tools/testing/selftests/bpf/progs/arena_race.c
[ ... ]
> +static __always_inline void wait_for_release(void)
> +{
> +	while (!*(volatile int *)&release && can_loop)
> +		;

[Severity: Medium]
Could this tight loop starve the CPU if preemption is disabled during the
fentry program?

On uniprocessor non-preemptible kernels, the userspace thread cannot be
scheduled to set the release variable while the BPF program runs. The loop
terminates only when can_loop runs out, which sets timed_out = 1 and causes
the test to fail.

> +	if (!*(volatile int *)&release)
> +		timed_out = 1;
> +}
[ ... ]
> +SEC("fentry/flush_tlb_kernel_range")
> +int BPF_PROG(trace_flush, unsigned long start, unsigned long end)

[Severity: Medium]
Does this fentry program fail to load on ARM64?

On ARM64, flush_tlb_kernel_range is defined as a static inline function in
<asm/tlbflush.h>. Because inline functions do not generate BTF IDs in
vmlinux, libbpf will fail to resolve the attach target during
arena_race__load(skel), which breaks the selftest CI on ARM64.

> +{
> +	if (!pause_on_flush ||
> +	    (__u32)bpf_get_current_pid_tgid() != target_tid)
> +		return 0;
> +	flush_entered = 1;
> +	wait_for_release();
> +	return 0;
> +}

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