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

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/[email protected]

> __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 all of these should be using type tags, but we're not there yet.

It is on my list of things to explore whether we can convert existing users of
KF_ARENA_ARG<N> flags (bpf_arena_alloc_pages(), etc.). We will have to modify
the implementation, and ensure we don't break compatibility by moving from
ignoring the type of input register to something we constrain to PTR_TO_ARENA
and SCALAR.

At that point, it should be possible to drop the kfunc flags, esp. if we are
worried about fragmenting ways of achieving the same thing (annotation of
vmlinux.h prototypes).

In functional terms, the only change on resolve_btfids side should be to use the
BTF parameter's emitted name for deciding whether it should trigger behavior
equivalent to the current KF_ARENA_ARG flags.

For better or worse, we need to be in this state of supporting suffixes until we
can declare bankruptcy of supporting GCC versions without type tags support.

> [...]