Message-ID: <bb4a868d-d4e2-40dc-aed4-4788b159a7f6@189.cn>
Date: Fri, 30 Jan 2026 10:17:53 +0800
From: Song Chen <chensong_2000@....cn>
To: Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc: Martin KaFai Lau <martin.lau@...ux.dev>,
 Alexei Starovoitov <ast@...nel.org>, Daniel Borkmann <daniel@...earbox.net>,
 Andrii Nakryiko <andrii@...nel.org>, Eduard <eddyz87@...il.com>,
 Song Liu <song@...nel.org>, Yonghong Song <yonghong.song@...ux.dev>,
 John Fastabend <john.fastabend@...il.com>, KP Singh <kpsingh@...nel.org>,
 Stanislav Fomichev <sdf@...ichev.me>, Hao Luo <haoluo@...gle.com>,
 Jiri Olsa <jolsa@...nel.org>, bpf <bpf@...r.kernel.org>,
 LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] kernel/bpf/btf.c: reject to register duplicated kfunc

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@....cn> wrote:
>>
>> From: Song Chen <chensong_2000@....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
> 

Powered by blists - more mailing lists