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

["Kumar Kartikeya Dwivedi" <memxor@gmail.com>]

On Tue Aug 4, 2026 at 11:34 PM CEST, Eduard Zingerman wrote:
> On Tue, 2026-08-04 at 14:19 -0700, Ihor Solodrai wrote:
>> 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?
>
> That would be ideal, yes.
>
>> >
>> > 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
>
> We are deliberately lax when handling arena and don't do any kind of
> value tracking there. So e.g. the following won't work:
>
>   if (foo->ptr) {
>     ...
>     kfunc(foo->ptr);
>   }
>
> Unless compiler decides to keep foo->ptr in a register. I'm not sure
> whether enforcing non-null here from the verifier side is the right
> call.
>
>>   * 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?
>
> At the moment we have two consumers:
> - Planned sched_ext related kfuncs that need kernel space pointers.
> - Existing kfuncs with KF_ARENA_ARG:
>   - bpf_arena_alloc_pages
>   - bpf_arena_free_pages
>   - bpf_arena_reserve_pages
>   They, take a user space address. Looking at the code is appears that
>   all three can be changed to handle kernel space address.
>   On the other hand, neither of these *needs* the passed pointer to be
>   converted to a kernel side arena pointer. So that would be just some
>   useless work.

I don't think it's useless work, they translate manually because the actual page
table operations happen using the kernel address anyway. IMO they probably need
access to both, and having one gives other, but kaddr is more important for them
to actually carry out the page table manipulation.

>
> So there are two valid use cases.
>
> ...