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

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

On Tue Aug 4, 2026 at 11:19 PM CEST, 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?
>
>>
>> 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 agree that we should simply have one __arena tag. It has a well defined
meaning for the program already, so shouldn't be confusing when seen on input
argument in struct_ops callback, or when passed into a kfunc as an output.

From the kernel's PoV, as Ihor said, it will rebased to the kernel base.
I wouldn't unnecessarily burden the consumers of this stuff to worry about
which side it should be translated to, that can be unambiguously derived from
the context in which it is used.

Having the ability to specify __nullable also makes sense. If for nothing else,
we already do that for every other pointer argument in a kfunc, otherwise assume
the argument is non-NULL unless the kfunc definition specifically opts into a
non-NULL argument. As a side benefit, it leads to more optimized JIT sequence.

In Tejun's branch, this came up already: only one of the callback or kfunc
really needed the __nullable annotation, the other was supposed to accept a
proper argument without the need to represent optionality.

I think we should have had such behavior for global functions too, but when they
were first implemented we hardcoded OR_NULL into the received type for a memory
pointer, and thus live with explicit __nonnull annotation now, to avoid breaking
compat if we change default behavior.

> 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/20260713024414.3759854-1-tj@kernel.org/
>
>>
>> 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.
>>
>> ...