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

[Alexei Starovoitov]

On Sun, May 24, 2026 at 11:15 AM <bot+bpf-ci@xxxxxxxxxx> wrote:
>
> > diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
> > index 17d4ab0a8206..425c9f5c64fa 100644
> > --- a/kernel/bpf/btf.c
> > +++ b/kernel/bpf/btf.c
> > @@ -8673,6 +8673,47 @@ static int btf_check_iter_kfuncs(struct btf *btf, const char *func_name,
> >       return 0;
> >  }
> >
> > +static int btf_check_kfunc_name(struct btf *btf, const char *func_name, u32 kind)
> > +{
> > +#ifdef CONFIG_DEBUG_INFO_BTF_MODULES
> > +     struct btf_module *btf_mod, *tmp;
> > +#endif
> > +     s32 id;
> > +     int ret = 0;
> > +
> > +     if (!btf_is_module(btf))
> > +             goto out;
>
> During v2 review, Alexei Starovoitov suggested a different approach: instead
> of rejecting duplicate kfunc registration, he proposed allowing module kfuncs
> to override kernel kfuncs, similar to livepatching. He stated: "imo that's a
> more interesting use case than helping out-of-tree module to produce nicier
> error" and "I'm not convinced that we should be doing it... because ^^^ is
> what I think we should be doing instead."
>
> The author requested implementation guidance on how the override mechanism
> would determine which kfunc to call, but received no maintainer response.
>
> Should this implementation be reconsidered?

It was considered and I said later to defer this idea for now.
AI should consider the whole discussion thread instead of immediate replies.
I guess in this case the threads were broken into multiple
due to different subjects.

Song,
in the future please try to use one subject.

Also "kernel/bpf/btf.c:" is not a valid prefix.
I will fix it up while applying when trees are ffwded after pending PR.