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

[Ihor Solodrai <ihor.solodrai@linux.dev>]

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]
- KF_ARENA_* flags to pass through the address_space(1)

and now we are adding __arena suffix for auto-rebasing

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/