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

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

On Wed Aug 5, 2026 at 12:57 AM CEST, Ihor Solodrai wrote:
> On 8/4/26 2:51 PM, Eduard Zingerman wrote:
>> On Tue, 2026-08-04 at 23:46 +0200, Kumar Kartikeya Dwivedi wrote:
>>> 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:
>>>>> [...]
>>>>> 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.
>>
>> From what I see these function compute the page number by subtracting
>> user vm start from the pointer. So, if switched to a kernel pointer
>> that would uaddr -> kaddr -> (kaddr - start) / page_size.
>> Compared to current (uaddr - ustart) / page_size.
>> But we can live with that.
>>
>> What's an overall conclusion? A single __arena suffix and modified
>> existing consumers? What would be the semantics for __nullable?
>
> Apparently, we also have btf_decl_tag("arg:arena") and a type tag.
>
> So that's three different arena annotations already:
> - decl tag for PTR_TO_ARENA for global funcs [1]
> - type tags for BPF declarations [2]

I think both serve different purposes. It makes sense for it to be type tag,
e.g. for it to be able to go into typedefs, etc. All suffixes we have on kernel
side will probably otherwise be declaration tags excluding other similar cases
to arena (like __rcu).

> - KF_ARENA_* flags to pass through the address_space(1)
>
> and now we are adding __arena suffix for auto-rebasing

This would be a type tag if we could do it that way, unfortunately since it gets
applied on the kernel side, we have to use a suffix. __arena tag used in program
BTF for kfunc or struct_ops is not authoritative, it needs to come from the
kernel.

>
> It's a mess, gentlemen.
>
> Since the verifier already recognizes the type tags, shouldn't we
> be using them?..
>
> [1] https://lore.kernel.org/bpf/20240209040608.98927-11-alexei.starovoitov@gmail.com/
> [2] https://lore.kernel.org/bpf/20260602004120.17087-1-emil@etsalapatis.com/