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.

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.

Signed-off-by: Song Chen <chensong_2000@189.cn>
---
Changes in v2:
    - use btf_find_by_name_kind to compare kfunc name
---
 kernel/bpf/btf.c | 16 ++++++++++++++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
index 0de8fc8a0e0b..f0158c9c103c 100644
--- a/kernel/bpf/btf.c
+++ b/kernel/bpf/btf.c
@@ -8498,7 +8498,8 @@ static int btf_check_iter_kfuncs(struct btf *btf, const char *func_name,
 	return 0;
 }
 
-static int btf_check_kfunc_protos(struct btf *btf, u32 func_id, u32 func_flags)
+static int btf_check_kfunc_protos(struct btf *btf, u32 func_id, u32 func_flags,
+			const struct module *module)
 {
 	const struct btf_type *func;
 	const char *func_name;
@@ -8514,6 +8515,17 @@ static int btf_check_kfunc_protos(struct btf *btf, u32 func_id, u32 func_flags)
 	if (!func_name || !func_name[0])
 		return -EINVAL;
 
+	/* check if there is any duplicated kfunc in btf_vmlinux */
+	if (module) {
+		s32 id = btf_find_by_name_kind(bpf_get_btf_vmlinux(),
+					func_name, BTF_INFO_KIND(func->info));
+		if (id >= 0) {
+			pr_err("kfunc %s (id: %d) is already present in vmlinux.\n",
+						func_name, id);
+			return -EINVAL;
+		}
+	}
+
 	func = btf_type_by_id(btf, func->type);
 	if (!func || !btf_type_is_func_proto(func))
 		return -EINVAL;
@@ -8757,7 +8769,7 @@ static int __register_btf_kfunc_id_set(enum btf_kfunc_hook hook,
 
 	for (i = 0; i < kset->set->cnt; i++) {
 		ret = btf_check_kfunc_protos(btf, btf_relocate_id(btf, kset->set->pairs[i].id),
-					     kset->set->pairs[i].flags);
+					     kset->set->pairs[i].flags, kset->owner);
 		if (ret)
 			goto err_out;
 	}
-- 
2.43.0

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

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@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 ?

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.

> 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
> 

On Thu, Jan 29, 2026 at 6:18 PM Song Chen <chensong_2000@189.cn> 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@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 ?
>
> 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.

On 1/30/26 10:54, Alexei Starovoitov wrote:
> On Thu, Jan 29, 2026 at 6:18 PM Song Chen <chensong_2000@189.cn> 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@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 ?
>>
>> 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