Message-ID: <49e41217-d96e-4234-a18c-633cc22fbbd4@189.cn>
Date: Sat, 7 Feb 2026 21:55:21 +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



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

Powered by blists - more mailing lists