Re: [PATCH bpf-next 2/5] selftests/bpf: libarena: Fix can-loop zero variable definition

[Ihor Solodrai <ihor.solodrai@linux.dev>]

On 6/18/26 1:56 AM, Emil Tsalapatis wrote:
> BPF can_loop based loops require the index variable to stay imprecise.
> This means we must initialize them from a currently imprecise variable
> instead of directly assigning 0 to them, like so:
> 
> static volatile u32 zero = 0;
> 
> for (i = zero; i < NUM_LOOPS; i++) {
> 	/* loop body */
> }
> 
> The libarena implementation of this technique is currently faulty. For
> the technique to work, the variable must not be in a map. This includes
> the .rodata DATASEC map used for const variables. However, libarena
> still defines the zero variable as constant.
> 
> Modify the zero variable definition into a volatile variable. This
> change adds a complication caused by the compiler optimizing array
> derefences from
> 
> for (i = zero; i < NUM_LOOPS; i++) {
> 	val = *(ptr + i);
> }
> 
> into
> 
> for (i = zero; i < NUM_LOOPS; i++) {
> 	val = *ptr++;
> }
> 
> and causing verification failures. Use the barrier_var() clobber macro
> to prevent this optimization from taking place. After that, remove the
> bpf_for() invocations introduced in libarena for parallel spmc testing.
> 
> Reported-by: Eduard Zingerman <eddyz87@gmail.com>
> Signed-off-by: Emil Tsalapatis <emil@etsalapatis.com>
> ---
>  .../selftests/bpf/libarena/include/libarena/common.h     | 2 +-
>  .../bpf/libarena/selftests/test_asan_buddy.bpf.c         | 8 ++++++--
>  .../selftests/bpf/libarena/selftests/test_buddy.bpf.c    | 8 ++++++--
>  .../bpf/libarena/selftests/test_parallel_spmc.bpf.c      | 9 ++++-----
>  tools/testing/selftests/bpf/libarena/src/common.bpf.c    | 3 +--
>  5 files changed, 18 insertions(+), 12 deletions(-)
> 
> diff --git a/tools/testing/selftests/bpf/libarena/include/libarena/common.h b/tools/testing/selftests/bpf/libarena/include/libarena/common.h
> index a3eb1641ac36..931ace9a49e2 100644
> --- a/tools/testing/selftests/bpf/libarena/include/libarena/common.h
> +++ b/tools/testing/selftests/bpf/libarena/include/libarena/common.h
> @@ -43,7 +43,7 @@ struct {
>   * imprecise. To force the variable to be imprecise, initialize it with
>   * the opaque volatile variable 0 instead of the constant 0.
>   */
> -extern const volatile u32 zero;
> +volatile u32 zero __weak;
>  extern volatile u64 asan_violated;
>  
>  int arena_fls(__u64 word);
> diff --git a/tools/testing/selftests/bpf/libarena/selftests/test_asan_buddy.bpf.c b/tools/testing/selftests/bpf/libarena/selftests/test_asan_buddy.bpf.c
> index 256d62a03ce7..3266a28f53d7 100644
> --- a/tools/testing/selftests/bpf/libarena/selftests/test_asan_buddy.bpf.c
> +++ b/tools/testing/selftests/bpf/libarena/selftests/test_asan_buddy.bpf.c
> @@ -154,7 +154,8 @@ __weak int asan_test_buddy_oob(void)
>  	size_t sizes[] = {
>  		7, 8, 17, 18, 64, 256, 317, 512, 1024,
>  	};
> -	int ret, i;
> +	int ret;
> +	u32 i;
>  
>  	ret = buddy_init(&buddy);
>  	if (ret) {
> @@ -163,6 +164,7 @@ __weak int asan_test_buddy_oob(void)
>  	}
>  
>  	for (i = zero; i < sizeof(sizes) / sizeof(sizes[0]) && can_loop; i++) {
> +		barrier_var(i);

Looks like we are using two different idioms for keeping indices
imprecise and blocking the compiler optimization: the `barrier_var(i)`
like here, and `volatile u32 i` declaration in patches #4 and #5.

My understanding is the barrier is generally better performance-wise,
since volatile var would be re-loaded every time.

Does it make sense to converge on a single pattern (at least in the
context of libarena)?


> [...]