Re: [PATCH dwarves] btf_encoder: Infer arena kfunc arguments from suffixes

[Eduard Zingerman <eddyz87@gmail.com>]

On Tue, 2026-08-04 at 21:27 +0200, Kumar Kartikeya Dwivedi wrote:
> On Tue Aug 4, 2026 at 8:43 PM CEST, Ihor Solodrai wrote:
> > On 8/3/26 5:55 AM, Kumar Kartikeya Dwivedi wrote:
> > > The kernel verifier recognizes __arena and __arena_nullable parameter
> > > suffixes for registered kfuncs. These arguments need the matching
> > > address_space(1) BTF type attribute so bpftool emits usable declarations.
> > 
> > Hi Kartikeya,
> > 
> > +cc: Emil, Tejun
> > 
> > This patch is certainly a no-go, because of the ongoing effort to move
> > decl/type tag BTF generation from pahole to resolve_btfids [1][2]. I'm
> > going to send the last unlanded bits of that soon.
> > 
> > *If* we decide to make this change, it shouldn't be done in pahole.
> > 
> 
> Ah, I was unaware. Once you share those changes I'd be happy to rework this
> support for resolve_btfids instead (i.e., tack it wherever we do
> KF_ARENA_ARGS<N> handling right now).
> 
> > But even setting that aside:
> > 
> > > The kernel verifier recognizes __arena and __arena_nullable
> > > parameter suffixes for registered kfuncs.
> > 
> > This is not true. The only way the kernel can recognize an arena
> > argument is via one of the three kfunc flags: KF_ARENA_RET,
> > KF_ARENA_ARG1 and KF_ARENA_ARG2. No __arena suffix support exist:
> > 
> >   $ git log --oneline -n1
> >   7f333f85f83d (HEAD -> bpf-next, origin/for-next, origin/bpf-next, bpf-next/master, bpf-next/for-next, bpf-next/HEAD) Merge branch 'bpf-invalidate-rcu-pointers-after-final-spin-unlock'
> >   $ grep -r --include="*.[ch]" __arena  kernel/bpf/
> >     # ...nothing
> > 
> 
> Yeah, I worded it poorly, I meant it was supposed to gain support for those
> soon^TM, by way of the series here:
> https://lore.kernel.org/bpf/20260803125115.2264733-1-memxor@gmail.com
> 
> > __arena symbol is only used in sched_ext, libarena and selftests code
> > as an alias to __atrribute__((address_space(1))) or a type tag:
> > 
> >   $ grep -r --include="*.[ch]" 'define __arena '
> >   tools/sched_ext/include/scx/bpf_arena_common.bpf.h:#define __arena __attribute__((address_space(1)))
> >   tools/testing/selftests/bpf/libarena/include/bpf_arena_common.h:#define __arena __attribute__((address_space(1))) __attribute__((btf_type_tag("arena")))
> >   tools/testing/selftests/bpf/libarena/include/bpf_arena_common.h:#define __arena __attribute__((btf_type_tag("arena")))
> > 
> > AFAIR prior discussions that led to KF_ARENA_* flags implementation,
> > we decided to *not* add an __arena arg suffix support. We were talking
> > about getting rid of this suffix-annotation mechanism completely.
> > 
> > What we want long term is proper decl/type tags support from
> > compilers, so that in the kernel we could have and use:
> > 
> >   #define __arena __attribute__((btf_type_tag("arena")))
> > 
> > At the time KF_ARENA_* flags were introduced, this wasn't feasible
> > because GCC compiler didn't support the tags. I think it does since
> > recently, but even so we'll have to support older compiler builds for
> > quite a while.
> 
> I wasn't involved in the discussion for choosing the flag, so I do not remember
> the nuance involved in making the choices back then. But please correct me or
> provide context in case I do not capture something accurately below.
> 
> > 
> > So while I understand the reluctance to add KF_ARENA_ARG3..N, I don't
> > think we want to introduce and support yet another mechanism for arena
> > argument annotations. If we do, we'll be stuck with a mess of
> > supporting two/three ways of doing the same thing for the foreseeable future.
> 
> I think one major difference is that KF_ARENA_ARG* things were mostly for
> annotating the vmlinux.h with the right address space label before, but didn't
> carry any semantic meaning for the kfunc's type checks.
> 
> That changes with these suffixes though. The pointer will be translated when
> passed into the kfunc. IMO it would be odd to diverge for this particular case,
> since we use suffixes for every other case where we constrain the input type of
> the kfunc argument or give it special meaning.
> 
> We also want to have similar annotation on struct_ops callbacks, where we also
> use suffixes, so it seemed better to keep it consistent.

I agree that we should follow the principle of least surprise here and
use suffixes, as everything else uses suffixes as well.

And yes, the __arena and KF_ARENA_ARG* annotations have different
semantics:
- __arena means that user space arena address is passed as is
- KF_ARENA_ARG* means that a user space address is converted
  to a kernel space address before passing.

It appears, though, that from the BPF program side having an address
space annotation on the kfunc parameter would be helpful, as it avoids
an additional cast.

Tbh, it sounds like we want __arena_user and __arena_kern suffixes.

> I agree that all of these should be using type tags, but we're not there yet.

Let's put aside the type tags discussion for the time being.

...