Re: [PATCH bpf-next v1 1/6] bpf: implement KF_IMPLICIT_PROG_AUX_ARG flag

Alexei Starovoitov
2025-09-25T19:35:10Z

On Thu, Sep 25, 2025 at 6:23 PM Andrii Nakryiko
<andrii.nakryiko@gmail.com> wrote:
>
> I do see the benefit of having the generic "KF_MAGIC_ARG(s)" flag on
> the kernel side of things and having access to full BTF information
> for parameters to let verifier know what specific kind of magic
> argument that kfunc has, though. So as an alternative, maybe we can
> create both a kfunc definition *meant for BPF programs* (i.e., without
> magic argument(s)), and then have a full original definition (produced
> by pahole, it will need to understand KF_MAGIC_ARGS anyways) with full
> type information *for internal BPF verifier needs*. I don't know
> what's the best way to do that, maybe just a special ".magic" suffix,
> just to let the verifier easily find that? On the kernel side, if
> kfunc has BPF_MAGIC_ARGS kflag we just look up "my_fancy_kfunc.magic"
> FUNC definition?

Interesting idea. Maybe to simplify backward compat the pahole can
emit two BTFs: kfunc_foo(args), kfunc_foo_impl(args, void *aux)
into vmlinux BTF.
bpftool will emit both in vmlinux.h and bpf side doesn't need to change.
libbpf doesn't need to change either.
The verifier would need a special check to resolve two kfunc BTFs
name into one kallsym name, since both kfuncs is one actual function
on the kernel.
bpf_wq_set_callback_impl() definition doesn't change. Only:
-BTF_ID_FLAGS(func, bpf_wq_set_callback_impl)
+BTF_ID_FLAGS(func, bpf_wq_set_callback_impl, KF_PROG_ARG)

and the verifier can check that the last arg is aux__prog when
KF_PROG_ARG is specified.

The runtime performance will be slightly better too, since
no need for wrappers like:

+__bpf_kfunc int bpf_wq_set_callback_impl(struct bpf_wq *wq,
+ int (callback_fn)(void *map, int *key, void *value),
+ unsigned int flags,
+ void *aux__prog)
+{
+ return bpf_wq_set_callback(wq, callback_fn, flags, aux__prog);
+}

It's just one jmpl insn, but still.