Re: [PATCH v2] kernel/bpf/btf.c: reject to register duplicated kfunc

[Alexei Starovoitov <alexei.starovoitov@gmail.com>]

On Thu, Jan 22, 2026 at 1:04 AM <chensong_2000@189.cn> wrote:
>
> From: Song Chen <chensong_2000@189.cn>
>
> I had an ebpf program which calls a kfunc defined and
> implemented in one of my kernel modules, they were working
> fine in 6.16, but was broken by libbpf in 6.19, the error
> message was:
>
> libbpf: extern (func ksym) 'bpf_strstr': func_proto [5]
> incompatible with vmlinux [94389]
>
> yes, the reason is there is a new added kfunc in kernel 6.19
> which happens to be the same name with my kfunc. However the
> error message is not obvious enough to address problem
> immediately.

I don't quite understand what you're trying to say.
"broken by libbpf"?! You mean that kernel 6.19 got
new kfunc bpf_strstr() ?
Why libbpf error is relevant?
You mean you had your own custom .h file where
you defined your own kfunc from a custom module
and libbpf complained that your bpf_strstr() kfunc
definition doesn't match the kernel 6.19 ?

and your proposed solution is ...

> Therefore, this patches searches duplicated kfunc in
> btf_vmlinux before a kernel module attempts to register kfuncs
> through register_btf_kfunc_id_set, it prints clear error message
> and returns error code if same name kfunc has already implemented
> and registered, then developer knows at the first place.

Are you saying that the kernel module that supplied bpf_strstr
shouldn't be allowed to register its kfunc if kfunc with
the same name exists in vmlinux. So insmod will fail?

This is debatable. I guess we can add such sanity check,
but what about kfunc in module A with the same name as kfunc
in module B?
Currently libbpf tells kernel both btf FD and kfunc btf ID,
though there is a single namespace for all kfuncs from bpf
program pov the kernel and libbpf api-s allow a selection.

Technically we can hack something in bpf.c to "namespace" kfuncs
and say that the kfunc "foo" is in the module "bar".
It won't be pretty in C, but possible in principle.

Maybe a kfunc with the same name in the module should be allowed
to override a kfunc in the kernel.
It can be seen as livepatching of kfuncs.
imo that's a more interesting use case than helping
out-of-tree module to produce nicier error.

pw-bot: cr