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

On 8/4/26 1:22 PM, Eduard Zingerman wrote:
> 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:
>>>> [...]
>>
>>>
>>> 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.

Ok, I understand the motivation. Let's say we use the suffixes.

Should this enable getting rid of KF_ARENA* flags then? For the
purposes of generating address_space(1), we can also just check the
name suffix, no?

> 
> 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.

Also I am a little confused about whether we *need* to be able to
express two distinct meanings of "arena pointer" or not?

My understanding is that "arena pointer" is a feature of an arg type
that has a single meaning: the pointer has one base in BPF world, and
a different base when executed in the kernel.

The things that are missing is auto-conversion (Tejun's RFC [1]) and more
comprehensive support of PTR_TO_ARENA in the verifier.

This is still only one "arena" annotation per arg. Do we actually need
the proliferation of __arena, __arena__nullable and/or __arena_kern,
__arena_user? Can't we have a single defined semantics of how arena
pointers are supposed to work?

I can imagine something like follows:
  * arena pointers can not be null, check for nulls
    before passing from BPF prog to the kernel
  * arena pointers are converted to the kernel space for
    kfunc/struct_ops callback by the verifier

With the documented and enforced semantics like this one way of
annotating and one annotation should be enough.

What am I missing?

[1] https://lore.kernel.org/bpf/[email protected]/

> 
> 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.
> 
> ...