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

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

On Tue Jun 30, 2026 at 3:28 PM EDT, Ihor Solodrai wrote:
> 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)?
>

I'm not sure we need to completely standardize because each idiom has its
uses, but I do like the idea of mostly using one of the two patterns. I
will try using volatile here to see if it prevents the loop optimizations
and will update it next version if it works.

>
>> [...]