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

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

On 3/21/26 1:27 PM, Alexei Starovoitov wrote:
> On Wed, Mar 18, 2026 at 4:42 PM Ihor Solodrai <ihor.solodrai@linux.dev> wrote:
>>
>>                                         const struct btf *btf,
>> @@ -12594,6 +12620,14 @@ enum special_kfunc_type {
>>         KF_bpf_session_is_return,
>>         KF_bpf_stream_vprintk,
>>         KF_bpf_stream_print_stack,
>> +       KF_bpf_obj_new,
>> +       KF_bpf_percpu_obj_new,
>> +       KF_bpf_obj_drop,
>> +       KF_bpf_percpu_obj_drop,
>> +       KF_bpf_refcount_acquire,
>> +       KF_bpf_list_push_front,
>> +       KF_bpf_list_push_back,
>> +       KF_bpf_rbtree_add,
>>  };
> 
> it's not an uapi. no need to add them to the end.
> Pls add them next to _impl flavors.
> 
> The whole thing needs a full refactor in a long term.
> special_kfunc* thingy got out of hand.

I thought about this a little and tried a couple of ideas.  Here is
one that looks a bit better to me than KF_* enum: BTF_ID_LIST_NAMED()
and BTF_ID_NAMED().

I vibe-coded a PoC [1]. Essentially, we add a set of macros to
generate source-level stable symbol for each BTF_ID_LIST entry. Then
it is possible to refer to the associated value directly by name.

It looks like this:

+#define BTF_ID_LIST_NAMED(name)                                \
+       __BTF_ID_LIST(name, local)                      \
+       extern u32 name[];
+
+#define BTF_ID_NAMED(list, prefix, name)               \
+       __BTF_ID(__BTF_ID__##prefix##__##name##__##list, "") \
+       extern u32 __btf_id_##list##__##prefix##__##name \
+               asm("__BTF_ID__" #prefix "__" #name "__" #list);
+
+#define btf_id_named(list, prefix, name) \
+       (__btf_id_##list##__##prefix##__##name)
+

And then:

+BTF_ID_LIST_NAMED(special_kfunc_list)
+BTF_ID_NAMED(special_kfunc_list, func, bpf_obj_new_impl)
+BTF_ID_NAMED(special_kfunc_list, func, bpf_obj_drop_impl)

  [...]

+#define special_kfunc_id(name) btf_id_named(special_kfunc_list, func, name)

  [...]

 static bool is_bpf_obj_new_kfunc(u32 func_id)
 {
-       return func_id == special_kfunc_list[KF_bpf_obj_new] ||
-              func_id == special_kfunc_list[KF_bpf_obj_new_impl];
+       return func_id == special_kfunc_id(bpf_obj_new) ||
+              func_id == special_kfunc_id(bpf_obj_new_impl);
 }


The benefit of this is that we can delete enum special_kfunc_type, and
there is only one list where a special kfunc has to be defined (and this
may work for other similar use cases).

The downside is additional BTF_ID macrology, and potentially changes
in resolve_btfids.

What do people think, is this worth pursuing?

[1] https://github.com/theihor/bpf/commit/be38dde0a027d7ab84d8d20ac266251fb938ceb6

> 
> pw-bot: cr