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

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

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@linux.dev/
>>
>> *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.
>>
>>>
>>>> [...]