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

[Song Chen <chensong_2000@126.com>]

Hi,

在 2026/5/24 17:42, Alexei Starovoitov 写道:
> On Sun, May 24, 2026 at 11:15 AM <bot+bpf-ci@kernel.org> 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