Re: [PATCH V2 1/2] tools/lib/bpf/libbpf: Prioritize module kfuncs over vmlinux kfuncs

[Song Chen <chensong_2000@126.com>]

On 5/12/26 09:33, Kumar Kartikeya Dwivedi wrote:
> On Sun, 10 May 2026 at 05:05, Song Chen <chensong_2000@126.com> wrote:
>>
>> Change the kfunc resolution order in find_ksym_btf_id() to search
>> module BTFs before vmlinux BTF. This allows kernel modules to override
>> vmlinux kfuncs with the same name, enabling a form of live-patching
>> for kfuncs.
>>
>> Previously, vmlinux kfuncs were always preferred, making it impossible
>> for modules to provide enhanced or fixed versions of existing kfuncs.
>> With this change, modules can now override kernel kfuncs, while
>> programs that don't use module BTFs remain unaffected.
>>
>> Suggested-by: Alexei Starovoitov <alexei.starovoitov@gmail.com>
>> Signed-off-by: Song Chen <chensong_2000@126.com>
>>
>> ---
>> changelog:
>> v1 -->  v2:
>> 1, introduce namespace to specify which module the kfunc belongs to, like:
>> modulea__foo
>> moduleb__foo
>> foo
>> As a result, kfunc foo can co-exist in modulea, moduleb and vmlinux, ebpf
>> code owner can specify which one he wants to call.
>> ---
>>   tools/lib/bpf/libbpf.c | 60 +++++++++++++++++++++++++++++++-----------
>>   1 file changed, 45 insertions(+), 15 deletions(-)
>>
> 
> Instead of modulea___ prefix, how about using declaration tags instead?
> We can use `namespace:vmlinux` and `namespace:module` to choose
> precedence for module or vmlinux.
> Then further scope using `namespace:moduleA` or `namespace:moduleB`.
> 

Thanks for the suggestion. Just to clarify — are you proposing this
as a BTF/string-level naming convention, or as something that would
appear in actual C identifiers? Since colons aren't valid in C
identifiers, I want to make sure I understand the intended mechanism.


> By default, I think preferring vmlinux symbols over modules makes
> sense. If one wants to prefer an overload with the same name coming
> from a module, they can place the right tag. But we need more
> consensus from other folks before you respin again. If we didn't have
> a way of indicating the preference, I would agree picking the one in
> module would allow more interesting cases by default, but since we do
> have a mechanism, it makes sense to pick a more sensible conservative
> default, in my opinion.
> 
> Anyway, let's see what others might say.
> 
yes, many thanks.

Best regards,

Song

> pw-bot: cr
> 
>> [...]