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.

...