Re: [PATCH bpf-next v1 05/10] selftests/bpf: Add tests for KF_IMPLICIT_ARGS

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

On 1/9/26 3:25 PM, Andrii Nakryiko wrote:
> On Fri, Jan 9, 2026 at 10:49 AM Ihor Solodrai <ihor.solodrai@linux.dev> wrote:
> 
> [...]
> 
>> diff --git a/tools/testing/selftests/bpf/test_kmods/bpf_testmod.c b/tools/testing/selftests/bpf/test_kmods/bpf_testmod.c
>> index 1c41d03bd5a1..503451875d33 100644
>> --- a/tools/testing/selftests/bpf/test_kmods/bpf_testmod.c
>> +++ b/tools/testing/selftests/bpf/test_kmods/bpf_testmod.c
>> @@ -1136,6 +1136,10 @@ __bpf_kfunc int bpf_kfunc_st_ops_inc10(struct st_ops_args *args)
>>  __bpf_kfunc int bpf_kfunc_multi_st_ops_test_1(struct st_ops_args *args, u32 id);
>>  __bpf_kfunc int bpf_kfunc_multi_st_ops_test_1_impl(struct st_ops_args *args, void *aux_prog);
>>
>> +__bpf_kfunc int bpf_kfunc_implicit_arg(int a, struct bpf_prog_aux *aux);
>> +__bpf_kfunc int bpf_kfunc_implicit_arg_legacy(int a, int b, struct bpf_prog_aux *aux);
>> +__bpf_kfunc int bpf_kfunc_implicit_arg_legacy_impl(int a, int b, void *aux__prog);
>> +
>>  BTF_KFUNCS_START(bpf_testmod_check_kfunc_ids)
>>  BTF_ID_FLAGS(func, bpf_testmod_test_mod_kfunc)
>>  BTF_ID_FLAGS(func, bpf_kfunc_call_test1)
>> @@ -1178,6 +1182,9 @@ BTF_ID_FLAGS(func, bpf_kfunc_st_ops_test_pro_epilogue, KF_SLEEPABLE)
>>  BTF_ID_FLAGS(func, bpf_kfunc_st_ops_inc10)
>>  BTF_ID_FLAGS(func, bpf_kfunc_multi_st_ops_test_1)
>>  BTF_ID_FLAGS(func, bpf_kfunc_multi_st_ops_test_1_impl)
>> +BTF_ID_FLAGS(func, bpf_kfunc_implicit_arg, KF_IMPLICIT_ARGS)
>> +BTF_ID_FLAGS(func, bpf_kfunc_implicit_arg_legacy, KF_IMPLICIT_ARGS)
>> +BTF_ID_FLAGS(func, bpf_kfunc_implicit_arg_legacy_impl)
> 
> (irrelevant, now that I saw patch #8 discussion, but for the future
> the point will stand and we can decide how resolve_btfids handles this
> upfront)
> 
> I'm wondering, should we add KF_IMPLICIT_ARGS to legacy xxx_impl
> kfuncs as well to explicitly mark them to resolve_btfids as legacy
> implementations? And if we somehow find xxx_impl without it, then
> resolve_btfids complains louds and fails, this should never happen?

Eh... I don't like the idea of flagging both foo and foo_impl.

If we use the same flag for legacy funcs, the flag becomes
insufficient to determine whether a function is legacy or not: we also
have to check the name (or something). This could be a different flag,
but I don't like that either.

For legacy kfuncs that we want to support, I don't think we have to
enforce anything. We allow to use old API, and the new one if it's
implemented.

Are you suggesting to ban _impl suffix in names of new kfuncs?
Fail build on accidental name collision?

We could implement sanity checks like these as separate passes in
resolve_btfids, for example.

> 
> 
> 
>>  BTF_KFUNCS_END(bpf_testmod_check_kfunc_ids)
>>
>>  static int bpf_testmod_ops_init(struct btf *btf)
>> @@ -1669,6 +1676,25 @@ int bpf_kfunc_multi_st_ops_test_1_impl(struct st_ops_args *args, void *aux__prog
>>         return ret;
>>  }
>>
>> +int bpf_kfunc_implicit_arg(int a, struct bpf_prog_aux *aux)
>> +{
>> +       if (aux && a > 0)
>> +               return a;
>> +       return -EINVAL;
>> +}
>> +
>> +int bpf_kfunc_implicit_arg_legacy(int a, int b, struct bpf_prog_aux *aux)
>> +{
>> +       if (aux)
>> +               return a + b;
>> +       return -EINVAL;
>> +}
>> +
>> +int bpf_kfunc_implicit_arg_legacy_impl(int a, int b, void *aux__prog)
>> +{
>> +       return bpf_kfunc_implicit_arg_legacy(a, b, aux__prog);
>> +}
>> +
>>  static int multi_st_ops_reg(void *kdata, struct bpf_link *link)
>>  {
>>         struct bpf_testmod_multi_st_ops *st_ops =
>> --
>> 2.52.0
>>