Re: [PATCH bpf-next v4 1/2] bpf: Support struct btf_struct_meta via KF_IMPLICIT_ARGS

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

On 3/26/26 8:45 PM, Kumar Kartikeya Dwivedi wrote:
> On Fri, 27 Mar 2026 at 01:28, Ihor Solodrai <ihor.solodrai@linux.dev> wrote:
>>
>> The following kfuncs currently accept void *meta__ign argument:
>>   * bpf_obj_new_impl
>>   * bpf_obj_drop_impl
>>   * bpf_percpu_obj_new_impl
>>   * bpf_percpu_obj_drop_impl
>>   * bpf_refcount_acquire_impl
>>   * bpf_list_push_front_impl
>>   * bpf_rbtree_add_impl
>>
>> The __ign suffix is an indicator for the verifier to skip the argument
>> in check_kfunc_args(). Then, in fixup_kfunc_call() the verifier may
>> set the value of this argument to struct btf_struct_meta *
>> kptr_struct_meta from insn_aux_data.
>>
>> BPF programs must pass a dummy NULL value when calling these kfuncs.
>>
>> Additionally, the list and rbtree _impl kfuncs also accept an implicit
>> u64 argument, which doesn't require __ign suffix because it's a
>> scalar, and BPF programs explicitly pass 0.
>>
>> Add new kfuncs with KF_IMPLICIT_ARGS [1], that correspond to each
>> _impl kfunc accepting meta__ign. The existing _impl kfuncs remain
>> unchanged for backwards compatibility.
> 
> Just a drive-by idle thought, but is there a way we could drop these
> _impl variants too eventually?

I think we *could*, since we don't promise stable API for kfuncs.

But practically speaking, turning this off abruptly will make many
people sad:

  $ git log -1 --oneline  958cf2e273f0 
  958cf2e273f0 bpf: Introduce bpf_obj_new

  $ git tag --contains 958cf2e273f0 --sort=creatordate | grep -v rc | head -n3
  v6.2
  v6.3
  v6.4

> 
> I think the existing macros in selftests can be updated to use either
> version by detecting the presence of the kfuncs, and maybe we can emit
> a warning to the stderr stream of the program during verification when
> we see these being used that they're going to go away in N releases,
> and then just drop them after that?

Selftests can just be moved to new API exclusively, since they are in
tree. Although we probably want to know that "legacy" is working for now.

More difficult problem is how to properly warn the users if we decide
to drop old _impl kunfcs, and for how long do we want to support both.
Do we already have some kind of "warning: deprecated" mechanism in the
verifier? I'm not aware.


> 
>>
>> [...]