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

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

On 8/4/26 3:05 PM, Eduard Zingerman wrote:
> On Tue, 2026-08-04 at 14:55 -0700, Ihor Solodrai wrote:
>> On 8/4/26 2:34 PM, 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:
>>>>>>>> [...]
>>>>>>
>>>>
>>>> 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.
>>>
>>> So there are two valid use cases.
>>
>> I think having more than one way of how to pass an arena pointer to
>> the kernel will create more confusion than bring value.
> 
> That might be the case.
> 
>> It seems to me the existing bpf_arena_* kfuncs accept user space
>> address for historical reasons (we just tried something that worked),
>> not by design exactly.
> 
> What makes you think so?

The fact that sched_ext needs to use a different way, which is why
this thread exists.  But you may be right that these are just two
different use-cases, and each does what makes sense for it.

> 
>> btw, Eduard, I get very confused by how you say "user space".. you
>> mean the 32bit value representing the BPF arena pointer, right?
> 
> Nope:
> 
>   static long compute_pgoff(struct bpf_arena *arena, long uaddr)
>   {
> 	return (u32)(uaddr - (u32)arena->user_vm_start) >> PAGE_SHIFT;
>   }
> 
>   static int arena_reserve_pages(struct bpf_arena *arena, long uaddr, u32 page_cnt)
>   {
> 	...
> 	if (uaddr & ~PAGE_MASK)
> 		return 0;
> 
> 	pgoff = compute_pgoff(arena, uaddr);
> 	if (pgoff + page_cnt > page_cnt_max)
> 		return -EINVAL;
> 	...
>    }
> 
>   __bpf_kfunc int bpf_arena_reserve_pages(void *p__map, void *ptr__ign, u32 page_cnt)
>   {
> 	...
> 	return arena_reserve_pages(arena, (long)ptr__ign, page_cnt);
>   }
> 
> ptr__ign/uaddr is a 64-bit user space address.

I see, thanks for the explanation.

> 
>>
>> Anyways, I think we should converge on the approach to arena pointers
>> handling before landing anything.
>>
>> Let's use __arena suffix as annotation mechanism, fine. But
>> I really wouldn't like to end up with N annotations for each
>> permutation of (non-)nullable and kern/user...
>>
>> I'll submit the resolve_btfids patches asap to not block on that.
>>
>>
>>>
>>> ...