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

[Song Chen]

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.

> 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