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

From: Kumar Kartikeya Dwivedi

Date: Mon May 11 2026 - 21:34:11 EST


On Sun, 10 May 2026 at 05:05, Song Chen <chensong_2000@xxxxxxx> wrote:
>
> Change the kfunc resolution order in find_ksym_btf_id() to search
> module BTFs before vmlinux BTF. This allows kernel modules to override
> vmlinux kfuncs with the same name, enabling a form of live-patching
> for kfuncs.
>
> Previously, vmlinux kfuncs were always preferred, making it impossible
> for modules to provide enhanced or fixed versions of existing kfuncs.
> With this change, modules can now override kernel kfuncs, while
> programs that don't use module BTFs remain unaffected.
>
> Suggested-by: Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx>
> Signed-off-by: Song Chen <chensong_2000@xxxxxxx>
>
> ---
> changelog:
> v1 --> v2:
> 1, introduce namespace to specify which module the kfunc belongs to, like:
> modulea__foo
> moduleb__foo
> foo
> As a result, kfunc foo can co-exist in modulea, moduleb and vmlinux, ebpf
> code owner can specify which one he wants to call.
> ---
> tools/lib/bpf/libbpf.c | 60 +++++++++++++++++++++++++++++++-----------
> 1 file changed, 45 insertions(+), 15 deletions(-)
>

Instead of modulea___ prefix, how about using declaration tags instead?
We can use `namespace:vmlinux` and `namespace:module` to choose
precedence for module or vmlinux.
Then further scope using `namespace:moduleA` or `namespace:moduleB`.

By default, I think preferring vmlinux symbols over modules makes
sense. If one wants to prefer an overload with the same name coming
from a module, they can place the right tag. But we need more
consensus from other folks before you respin again. If we didn't have
a way of indicating the preference, I would agree picking the one in
module would allow more interesting cases by default, but since we do
have a mechanism, it makes sense to pick a more sensible conservative
default, in my opinion.

Anyway, let's see what others might say.

pw-bot: cr

> [...]