Re: [PATCH bpf-next v3 5/9] selftests/bpf: Add kfunc __arena and __arena_nullable argument tests

["Kumar Kartikeya Dwivedi" <memxor@gmail.com>]

On Tue Aug 4, 2026 at 10:01 PM CEST, Eduard Zingerman wrote:
> On Mon, 2026-08-03 at 14:51 +0200, Kumar Kartikeya Dwivedi wrote:
>
> ...
>
>> +SEC("syscall")
>> +__arch_x86_64
>> +__success __retval(0)
>> +int arena_arg_forms(void *ctx)
>> +{
>> +#if defined(__BPF_FEATURE_ADDR_SPACE_CAST)
>> +	u64 __arena *val;
>> +	u64 ret;
>> +
>> +	val = bpf_arena_alloc_pages(&arena, NULL, 1, NUMA_NO_NODE, 0);
>> +	if (!val)
>> +		return 1;
>> +
>> +	/* PTR_TO_ARENA argument */
>> +	*val = 41;
>> +	ret = bpf_kfunc_arena_arg_test((u64 *)val);
>
> Thinking a bit more about the PTR_TO_ARENA vs SCALAR_VALUE in the
> patch #1. Looking the test cases added, the use case is to pass
> pointers annotated with __attribute__((address_space(1))) to such
> functions, e.g. obtained as:
> - a return value from bpf_arena_alloc_pages
> - or a nested pointer in some arena located structure:
>   struct foo {
>     int __arena *ptr;
>   };
>   ...
>   sturct foo __arena *foo = ...;
>   bpf_kfunc_arena_arg_test(foo->ptr);
>
> The way these kfuncs are currently generated in vmlinux.h,
> they lack the address space annotation, and hence you need
> to explicitly do the casting, as here:
>
>   ret = bpf_kfunc_arena_arg_test((u64 *)val);

For now they are in bpf_testmod, but your point stands regardless.

>
> This is both inconvenient *and* adds a useless address space cast
> instruction (translation of the cast).
>
> Which leads to several conclusions:
> - We should reach a consensus regarding KF_ARENA* usage, as these
>   kfuncs would clearly benefit from having __arena annotations on
>   parameters (on the BPF side, on the host side these should be
>   declared as plain pointers).

Yes, but even if we do, for the time begin, we won't have support for
automatically emitting it until resolve_btfids changes are done. That said, I
can manually add the annotation for now.

> - In patch #1, it appears that there is no need to allow PTR_TO_ARENA
>   for parameters passed to such a function. At-least I don't see a C
>   code not involving manual casts that would require such support.

This one I don't understand. Why wouldn't we get PTR_TO_ARENA typed paramters as
arguments?

>
> ...