Re: [PATCH v2] kernel/bpf/btf.c: reject to register duplicated kfunc
From: Song Chen
Date: Sat Feb 07 2026 - 09:00:17 EST
On 1/30/26 10:54, Alexei Starovoitov wrote:
On Thu, Jan 29, 2026 at 6:18 PM Song Chen <chensong_2000@xxxxxx> wrote:
hi,
my comments are in line, thanks.
Song
在 2026/1/28 12:28, Alexei Starovoitov 写道:
On Thu, Jan 22, 2026 at 1:04 AM <chensong_2000@xxxxxx> wrote:
From: Song Chen <chensong_2000@xxxxxx>
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 ?
let me explain:
I had a module, defined a kfunc(bpf_strstr) in its c file and register
it through register_btf_kfunc_id_set.I also had a ebpf program to use
bpf_strstr in this module.
They were working fine in kernel 6.16, but kernel 6.19 has its own
bpf_strstr, so when i ran my ebpf program in kernel 6.19, libbpf broke
it here:
bpf_object__resolve_ksym_func_btf_id
--bpf_core_types_are_compat
--__bpf_core_types_are_compat
yes, your understanding is pretty much correct.
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?
yes, two kfuncs of bpf_strstr are registered in the system and one of
them is never used, this is a problem.
This is debatable. I guess we can add such sanity check,
agree, even it's not a big deal.
but what about kfunc in module A with the same name as kfunc
in module B?
It's in my plan, also go through "list_for_each_entry_safe(btf_mod, tmp,
&btf_modules, list)", but i haven't gone that far yet, i can add it.
I'm not convinced that we should be doing it.
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.
because ^^^ is what I think we should be doing instead.
Since it is more applicable and useful.
I'd like to hear what other folks are thinking
If I understand you correctly, you need both kfuncs to co-exist and kfunc in module has higher priority.
I did some research and test:
kfunc addr is set in function add_kfunc_call by calling kallsyms_lookup_name(func_name), if it calls module_kallsyms_lookup_name(func_name) instead, it will get the kfunc in module and it works like a livepatch literally.
The problem is how can we know which one should be called, insn->off seems to indicate kfunc is from module if it's bigger than 0, but it's 0 in this case.
Any advice in this case?
/Song