Re: [PATCH bpf v2 1/2] bpf: Fix tracing of kfuncs with implicit args

[Ihor Solodrai]

On 2026-07-11 4:51 p.m., Eduard Zingerman wrote:
> On Sat, 2026-07-11 at 10:57 -0700, Ihor Solodrai wrote:
> > On 2026-07-11 3:43 a.m., Eduard Zingerman wrote:
> > > On Fri, 2026-07-10 at 12:29 -0700, Ihor Solodrai wrote:
> > >
> > > [...]
> > >
> > > If I am not confused, I think that resolve_btfids() has to verify that
> > > kfunc flags are always the same across multiple sets.
> >
> > Some form of build-time enforcement will be implemented as part of
> > resolve_btfids() BTF handling, see the v1 here:
> > https://lore.kernel.org/bpf/20260601221805.821394-1-ihor.solodrai@xxxxxxxxx/
> >
> > *If* you're right about no valid use-case for incosistent kfunc flags,
> > then long-term I agree: build-time enforcement of consistency, and
> > then the acummulation can be replaced by a search (find first) here.
> >
> > But this has to be confirmed somehow (by thoroughly inspecting all
> > current inconsistencies and flags?..)
> >
> > However if there is even one valid use-case, then we are in trouble,
> > because then depending on the flag semantics it may or may not make
> > sense for it to be consistent accross kfunc sets. And it's not even
> > clear what a good solution to that might look like: separate groups of
> > flags? consistency enforcement for some flags, but not others (this is
> > literally what Andrii suggested in resolve_btfids thread)?
> >
> > Accumulating flags across the sets is an acceptable workaround for
> > this fix IMO. We can be more specific and *only* check for the
> > KF_IMPLICIT_ARGS for the purposes of this fix though, but we still
> > have to walk all hooks and OR.
>
> And what would that mean for the same function to have
> KF_IMPLICIT_ARGS in one set and not to have it in another?

That would mean a bug in a kfunc set declaration, yeah.

> Given that actual function address is resolved to the exact same
> function. Such accumulator would only proliferate already confusing
> behaviour.
>
> I don't think that the analysis of existing cases would take longer
> than 1-2h.

It was silly of me to mention the analysis as an obstacle (which I'm
not excited to do, sure). We are at -rc3, so there is a couple of
weeks still if we are targeting 7.2

But resolve_btfids series is certainly a merge-window thing, so the
fix shouldn't depend on it. And even carving out build-time KF_ flag
consistentcy enforcement from there is too potentially disruptive for
a "fix" IMO.

How about the following plan.

In the fix:
  * delete btf_kfunc_accumulated_flags()
  * expose (back) btf_kfunc_id_set_contains() from btf.c
  * in btf_attach_func_proto() walk the hooks and specifically check
    for *consistent* KF_IMPLICIT_ARGS
  * -EINVAL on inconsistency

In the v2 of resolve_btfids series (targeting 7.3):
  * implement kbuild/module-time enforcement of consistency
    for *all* KF_ flags
  * fix in-tree cases where that's not true
  * if there is a valid use-case, it should show up as a blocker, but
    I'll also eyeball all the kfunc set declarations

Does this make sense?

> > I don't think it's reasonable to wait for the comprehensive kfunc flags
> > analysis and resolve_btfids series landing before fixing the garbage
> > dereference bug.
> >
> > > > [...]