Re: [PATCH bpf v2 0/2] bpf: add _impl suffix for kfuncs with implicit args

[Mykyta Yatsenko <mykyta.yatsenko5@gmail.com>]

On 11/4/25 19:29, Andrii Nakryiko wrote:
> On Tue, Nov 4, 2025 at 9:23 AM Ihor Solodrai <ihor.solodrai@linux.dev> wrote:
>> On 11/4/25 7:29 AM, Mykyta Yatsenko wrote:
>>> We’re introducing support for implicit kfunc arguments and need to
>>> rename new kfuncs to comply with the naming convention.
>>> This new feature, will for each kfunc of the form:
>>>
>>> `bpf_foo_impl(args..., aux__prog)`
>>>
>>> generate a public BTF type:
>>>
>>> `bpf_foo(args...)`
>>>
>>> and the verifier will resolve calls to bpf_foo() to bpf_foo_impl(),
>>> supplying a valid struct bpf_prog_aux via aux__prog.
>> Hi Mykyta, thank you for submitting this.
>>
>> The explanation in this cover is inaccurate. There were a few
>> discussions, and the "implicit" feature is in active development, so
>> it is confusing... Let me try to elaborate.
>>
>> Currently if a kfunc needs access to struct bpf_prog_aux data, it must
>> have an explicit void *aux__prog argument in its declaration. Then on
>> BPF side the users must pass a dummy value (conventionally NULL).
>>
>> In the v6.18-rc4 these 4 functions are using aux__prog argument:
>>    * bpf_wq_set_callback_impl (note existing _impl suffix)
>>    * bpf_task_work_schedule_signal
>>    * bpf_task_work_schedule_resume
>>    * bpf_stream_vprintk
>>
>> The goal of the KF_IMPLICIT_ARGS feature is to hide this argument from
>> BPF programs, as it is supplied by the verifier.
>>
>> With it, the kfuncs still require an explicit argument in the
>> kernel declaration, for example:
>>
>>      __bpf_kfunc int bpf_foo(int arg, struct bpf_prog_aux *aux__implicit);
>>
>> In order to hide it from the BPF users, the following functions will
>> be produced in BTF from the above declaration:
>>
>>      /* no aux arg for BPF interface kfunc */
>>      __bpf_kfunc int bpf_foo(int arg);
>>
>>      /* no kfunc decl_tag for _impl function */
>>      int bpf_foo_impl(int arg, struct bpf_prog_aux *aux__implicit);
>>
>> Now the problem with existing aux__prog users that you're renaming in
>> this patchset is that because they don't have an _impl suffix, their
>> prototype will change, breaking binary compatibility with existing BPF
>> programs. If we simply mark them as KF_IMPLICIT_ARGS, then they lose
>> an argument in BTF, for example:
>>
>>      bpf_task_work_schedule_signal(task, tw, map__map, callback, aux__prog);
>>
>> becomes
>>
>>      bpf_task_work_schedule_signal(task, tw, map__map, callback);
>>
>> However, if we rename it to "bpf_task_work_schedule_signal_impl", then
>> after KF_IMPLICIT_ARGS feature is implemented, we can *add a new
>> kfunc* "bpf_task_work_schedule_signal" with an implicit arg.
>>
>> This way we can avoid breaking BPF progs calling this kfunc, although
>> renaming is still a disruption of course.
>>
>> See links to previous discussions:
>> * https://lore.kernel.org/bpf/20251029190113.3323406-1-ihor.solodrai@linux.dev/
>> * https://lore.kernel.org/bpf/20250924211716.1287715-1-ihor.solodrai@linux.dev/
>> * https://lore.kernel.org/dwarves/20250924211512.1287298-1-ihor.solodrai@linux.dev/
>>
>>> Three kfuncs added in 6.18 don’t follow this *_impl convention and
>>> therefore won’t participate in the new mechanism:
>>>   * bpf_task_work_schedule_resume()
>>>   * bpf_task_work_schedule_signal()
>>>   * bpf_stream_vprintk()
>>>
>>> Rename them to align with the implicit-arg flow:
>>> bpf_task_work_schedule_resume() -> bpf_task_work_schedule_resume_impl()
>>> bpf_task_work_schedule_signal() -> bpf_task_work_schedule_signal_impl()
>>> bpf_stream_vprintk() -> bpf_stream_vprintk_impl()
>>>
>>> The implicit-arg mechanism is not in tree yet, so callers must switch to
>>> the *_impl names for now. Once the new mechanism lands, the plain
>>> names (without _impl) will be reintroduced as BTF-visible entry points
>>> and will resolve to the _impl versions automatically.
>>>
> TBH, it looks like both Mykyta's and Ihor's descriptions are a little
> bit too detailed and are more concerned with details of the upcoming
> feature.
>
> What's important with these fixes is that we are fixing deviation from
> the previously established "_impl" suffix naming convention for these
> kfuncs that accept verifier-provided bpf_prog_aux arguments. Following
> uniform convention will allow for transparent backwards compatibility
> with the upcoming KF_IMPLICIT_ARGS feature, so this patch set aims to
> fix current deviation from the convention so as to eliminate
> unnecessary backwards incompatibility breakage in the future.
>
> WDYT?
Thanks, this message makes more sense, let me update commit descriptions 
and send v3.
>>> Signed-off-by: Mykyta Yatsenko <yatsenko@meta.com>
>>> ---
>>> Changes in v1:
>>> - Split commit into 2
>>> - Rebase on the correct branch
>>> - Link to v1: https://lore.kernel.org/all/20251103232319.122965-1-mykyta.yatsenko5@gmail.com/
>>>
>>> ---
>>> Mykyta Yatsenko (2):
>>>        bpf:add _impl suffix for bpf_task_work_schedule* kfuncs
>>>        bpf:add _impl suffix for bpf_stream_vprintk() kfunc
>>>
>>>   kernel/bpf/helpers.c                               | 26 +++++++++++---------
>>>   kernel/bpf/stream.c                                |  3 ++-
>>>   kernel/bpf/verifier.c                              | 12 +++++-----
>>>   tools/bpf/bpftool/Documentation/bpftool-prog.rst   |  2 +-
>>>   tools/lib/bpf/bpf_helpers.h                        | 28 +++++++++++-----------
>>>   tools/testing/selftests/bpf/progs/stream_fail.c    |  6 ++---
>>>   tools/testing/selftests/bpf/progs/task_work.c      |  6 ++---
>>>   tools/testing/selftests/bpf/progs/task_work_fail.c |  8 +++----
>>>   .../testing/selftests/bpf/progs/task_work_stress.c |  4 ++--
>>>   9 files changed, 50 insertions(+), 45 deletions(-)
>>> ---
>>> base-commit: 6146a0f1dfae5d37442a9ddcba012add260bceb0
>>> change-id: 20251104-implv2-d6c4be255026
>>>
>>> Best regards,