From: Song Chen <chensong_2000@126.com>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>,
Kaitao Cheng <kaitao.cheng@linux.dev>
Cc: bpf <bpf@vger.kernel.org>,
Martin KaFai Lau <martin.lau@linux.dev>,
Jiri Olsa <jolsa@kernel.org>, Hao Luo <haoluo@google.com>,
KP Singh <kpsingh@kernel.org>, Song Liu <song@kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Alexei Starovoitov <ast@kernel.org>,
Andrii Nakryiko <andrii@kernel.org>, Eduard <eddyz87@gmail.com>,
Yonghong Song <yonghong.song@linux.dev>,
John Fastabend <john.fastabend@gmail.com>,
Stanislav Fomichev <sdf@fomichev.me>
Subject: Re: [PATCH V2 1/2] tools/lib/bpf/libbpf: Prioritize module kfuncs over vmlinux kfuncs
Date: Thu, 14 May 2026 20:54:47 +0800 [thread overview]
Message-ID: <f61ecd8f-675d-41e6-bdad-4496f5ecd076@126.com> (raw)
In-Reply-To: <CAADnVQLNLd7kV+pBV1i7YvPoQGMVzJusS71iPs6oc_K0Qpd9fA@mail.gmail.com>
Hi;
On 5/13/26 05:41, Alexei Starovoitov wrote:
> On Mon, May 11, 2026 at 8:19 PM Kaitao Cheng <kaitao.cheng@linux.dev> wrote:
>>
>> It seems that there are two problems to solve here:
>>
>> 1. Allowing kernel modules to override vmlinux kfuncs with the same
>> name.
>>
>> This should be relatively straightforward to implement by matching
>> names in kernel modules first, and then falling back to vmlinux.
>>
>> 2. Handling the case where different kernel modules have kfuncs with
>> the same name.
>>
>> Could we use a new libbpf API to establish the mapping manually?
>> for example:
>> bpf_object__set_ksym_btf(obj, "kfunc_name", "module_name")
>>
>> Or define a new attribute, for example:
>> extern void kfunc_name(void) __ksym __module("module_name");
>>
>> We probably need to hear suggestions from other developers on this.
>
> I'm not excited about 2.
> Two different modules are not allowed to have two different functions
> with the same name.
> The kernel has only one global namespace.
> Hence I don't think we should be introducing such namespacing concept
> into kfuncs.
>
> But 1, I feel, is useful for experiments and mitigations,
> but it probably should be done transparently to libbpf.
>
> register_btf_kfunc_id_set() should be changed to return an error
> when a module attempts to register a kfunc with a name that already
> exists in the kernel.
> We also introduce override_btf_kfunc_set() that would register
> a replacement kfunc.
> override_btf_kfunc_set() would check that all overriding kfuncs
> have the exact same kfunc already in vmlinux BTF: proto and name should match.
> Then the kernel will just remember that the address of that kfunc
> is in the module.
> libbpf doesn't need to be aware of this substitution.
> It will find kfunc in the vmlinux BTF, but the verifier will supply
> implementation from the module to bpf prog.
> 2nd module should be able to override_btf_kfunc_set() from vmlinux
> and from 1st module that replaced some kfuncs.
> All that only for bpf progs that are loaded after override.
> Already loaded progs don't need to be live patched.
> Thoughts?
If i understand you correctly, you suggest instead of introduce
namespace in libbpf, we should replace kfunc in
vmlinux(btf->types[type_id]) with kfunc in modules by introducing
override_btf_kfunc_set.
In [1], I simply returned an error, your suggestion is a little further
than that, correct me if i'm wrong.
[1]:https://lore.kernel.org/all/20260122090404.15553-1-chensong_2000@189.cn/
best regards,
Song
next prev parent reply other threads:[~2026-05-14 12:56 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-10 3:01 Song Chen
2026-05-10 3:37 ` bot+bpf-ci
2026-05-12 1:33 ` Kumar Kartikeya Dwivedi
2026-05-14 12:37 ` Song Chen
2026-05-12 3:18 ` Kaitao Cheng
2026-05-12 21:41 ` Alexei Starovoitov
2026-05-14 12:54 ` Song Chen [this message]
2026-05-14 15:27 ` Alexei Starovoitov
2026-05-14 13:29 ` Kaitao Cheng
2026-05-17 6:31 ` Song Chen
2026-05-17 14:59 ` Alexei Starovoitov
2026-05-14 12:43 ` Song Chen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f61ecd8f-675d-41e6-bdad-4496f5ecd076@126.com \
--to=chensong_2000@126.com \
--cc=alexei.starovoitov@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=haoluo@google.com \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kaitao.cheng@linux.dev \
--cc=kpsingh@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=martin.lau@linux.dev \
--cc=sdf@fomichev.me \
--cc=song@kernel.org \
--cc=yonghong.song@linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®