Re: [PATCH V2 1/2] tools/lib/bpf/libbpf: Prioritize module kfuncs over vmlinux kfuncs

[Kaitao Cheng <kaitao.cheng@linux.dev>]

在 2026/5/13 05:41, Alexei Starovoitov 写道:
> On Mon, May 11, 2026 at 8:19 PM Kaitao Cheng <kaitao.cheng@linux.dev> wrote:
>>
>> It seems that there are two problems to solve here:
>>
>> 1. Allowing kernel modules to override vmlinux kfuncs with the same
>>    name.
>>
>>    This should be relatively straightforward to implement by matching
>>    names in kernel modules first, and then falling back to vmlinux.
>>
>> 2. Handling the case where different kernel modules have kfuncs with
>>    the same name.
>>
>>    Could we use a new libbpf API to establish the mapping manually?
>>    for example:
>>        bpf_object__set_ksym_btf(obj, "kfunc_name", "module_name")
>>
>>    Or define a new attribute, for example:
>>        extern void kfunc_name(void) __ksym __module("module_name");
>>
>>    We probably need to hear suggestions from other developers on this.
> 
> I'm not excited about 2.
> Two different modules are not allowed to have two different functions
> with the same name.
> The kernel has only one global namespace.
> Hence I don't think we should be introducing such namespacing concept
> into kfuncs.
> 
> But 1, I feel, is useful for experiments and mitigations,
> but it probably should be done transparently to libbpf.
> 
> register_btf_kfunc_id_set() should be changed to return an error
> when a module attempts to register a kfunc with a name that already
> exists in the kernel.
> We also introduce override_btf_kfunc_set() that would register
> a replacement kfunc.
> override_btf_kfunc_set() would check that all overriding kfuncs
> have the exact same kfunc already in vmlinux BTF: proto and name should match.
> Then the kernel will just remember that the address of that kfunc
> is in the module.
> libbpf doesn't need to be aware of this substitution.
> It will find kfunc in the vmlinux BTF, but the verifier will supply
> implementation from the module to bpf prog.
> 2nd module should be able to override_btf_kfunc_set() from vmlinux
> and from 1st module that replaced some kfuncs.

If multiple modules are allowed to call override_btf_kfunc_id_set()
for the same vmlinux kfunc, the effective implementation becomes
dependent on module load order.

For example, module A overrides a vmlinux kfunc and an A BPF program
is written with the expectation that this kfunc resolves to module A's
implementation. Later, developer B loads module B, which overrides the
same kfunc so that B's BPF program can work. If developer A then reloads
or reruns the A BPF program without knowing about module B's override,
the same kfunc may now resolve to module B's implementation. This can
make the behavior hard to debug and increase the maintenance cost of the
system.

If this is the intended semantics, I think override_btf_kfunc_id_set()
should have clear comments documenting that later overrides replace
earlier ones for future BPF program loads. It may also be useful to
expose some debugging visibility, e.g. through verifier logs, debugfs,
or bpftool, so users can tell whether a given kfunc currently resolves
to vmlinux or to a specific module.

If this is not intended, then we may need a mechanism to reject
overriding an already-overridden kfunc unless the caller explicitly
requests a forced replacement.

> All that only for bpf progs that are loaded after override.
> Already loaded progs don't need to be live patched.
> Thoughts?

-- 
Thanks
Kaitao Cheng