mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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


  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®