Re: [PATCH bpf-next v1 5/6] bpf: mark bpf_stream_vprink kfunc with KF_IMPLICIT_PROG_AUX_ARG

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

On 9/25/25 3:01 AM, Alexei Starovoitov wrote:
> On Wed, Sep 24, 2025 at 10:17 PM Ihor Solodrai <ihor.solodrai@linux.dev> wrote:
>>
>> Update bpf_stream_vprink macro in libbpf and fix call sites in
> 
> 't' is missing in bpf_stream_vprintk().
> 
>> the relevant selftests.
>>
>> Signed-off-by: Ihor Solodrai <ihor.solodrai@linux.dev>
>> ---
>>  kernel/bpf/helpers.c                            | 2 +-
>>  kernel/bpf/stream.c                             | 3 +--
>>  tools/lib/bpf/bpf_helpers.h                     | 4 ++--
>>  tools/testing/selftests/bpf/progs/stream_fail.c | 6 +++---
>>  4 files changed, 7 insertions(+), 8 deletions(-)
>>
>> diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c
>> index 6b46acfec790..875195a0ea72 100644
>> --- a/kernel/bpf/helpers.c
>> +++ b/kernel/bpf/helpers.c
>> @@ -4378,7 +4378,7 @@ BTF_ID_FLAGS(func, bpf_strnstr);
>>  #if defined(CONFIG_BPF_LSM) && defined(CONFIG_CGROUPS)
>>  BTF_ID_FLAGS(func, bpf_cgroup_read_xattr, KF_RCU)
>>  #endif
>> -BTF_ID_FLAGS(func, bpf_stream_vprintk, KF_TRUSTED_ARGS)
>> +BTF_ID_FLAGS(func, bpf_stream_vprintk, KF_TRUSTED_ARGS | KF_IMPLICIT_PROG_AUX_ARG)
> 
> This kfunc will be in part of 6.17 release in a couple days,
> so backward compat work is necessary.
> I don't think we can just remove the arg.

Acked.

> 
>> --- a/tools/lib/bpf/bpf_helpers.h
>> +++ b/tools/lib/bpf/bpf_helpers.h
>> @@ -316,7 +316,7 @@ enum libbpf_tristate {
>>  })
>>
>>  extern int bpf_stream_vprintk(int stream_id, const char *fmt__str, const void *args,
>> -                             __u32 len__sz, void *aux__prog) __weak __ksym;
>> +                             __u32 len__sz) __weak __ksym;
> 
> CI is complaining of conflicting types for 'bpf_stream_vprintk',
> since it's using pahole master.
> It will stop complaining once pahole changes are merged,
> but this issue will affect all developers until they
> update pahole.
> Not sure how to keep backward compat.

Right.

One way to do it is to conditionalize new kfunc defitions under a
config flag similar to how we have CONFIG_PAHOLE_HAS_SPLIT_BTF and co.

But this seems like too much trouble for just a couple of kfuncs,
especially since we do not guarantee stable interface for kfuncs.

We could ask people to update pahole version if they run into
issues. And they shouldn't unless they are actually using the kfuncs,
or more specifically: have their own declarations of said kfuncs.

bpf_stream_vprintk() is a special case, because it is already in
libbpf.