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

[Song Chen]

On 5/12/26 09:33, Kumar Kartikeya Dwivedi wrote:
> 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`.

Thanks for the suggestion. Just to clarify — are you proposing this
as a BTF/string-level naming convention, or as something that would
appear in actual C identifiers? Since colons aren't valid in C
identifiers, I want to make sure I understand the intended mechanism.


> 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.
yes, many thanks.

Best regards,

Song

> pw-bot: cr
>
> > [...]