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

[Song Chen]

Hi,

在 2026/5/24 17:42, 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.

will do. AI review is really amazing and I'm so impressed to its smartness.

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

will do and I appreciate it.

Song