Re: [PATCH bpf-next v3 5/9] selftests/bpf: Add kfunc __arena and __arena_nullable argument tests
Eduard Zingerman <[email protected]> Tue, 04 Aug 2026 13:01:36 -0700
| Newsgroups | org.kernel.vger.bpf |
|---|---|
| Message-ID | <[email protected]> |
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);
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).
- 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.
...