From: Kaitao Cheng <kaitao.cheng@linux.dev>
To: Song Chen <chensong_2000@126.com>
Cc: bpf@vger.kernel.org, martin.lau@linux.dev, ast@kernel.org,
alexei.starovoitov@gmail.com, daniel@iogearbox.net,
andrii@kernel.org, eddyz87@gmail.com, song@kernel.org,
yonghong.song@linux.dev, john.fastabend@gmail.com,
kpsingh@kernel.org, sdf@fomichev.me, haoluo@google.com,
jolsa@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3] kernel/bpf/btf.c: reject to register duplicated kfunc
Date: Mon, 25 May 2026 17:18:53 +0800 [thread overview]
Message-ID: <757e24eb-45d3-4e05-9aa2-f077bec8fea9@linux.dev> (raw)
In-Reply-To: <20260524082944.10625-1-chensong_2000@126.com>
在 2026/5/24 16:29, Song Chen 写道:
> I had an ebpf program which calls a kfunc defined and
> implemented in one of my kernel modules, it was working
> fine in 6.16, but was rejected to run by libbpf in 6.19,
> the error message was:
>
> libbpf: extern (func ksym) 'bpf_strstr': func_proto [5]
> incompatible with vmlinux [94389]
>
> The reason is there is a new added kfunc in kernel 6.19
> which happens to be the same name with my kfunc. However the
> error message is not obvious enough to address problem
> immediately.
>
> Therefore, this patches searches duplicated kfunc in
> both btf_vmlinux and btf_modules list before a kernel module
> attempts to register kfuncs through register_btf_kfunc_id_set,
> it prints clear error message and returns error code if same name
> kfunc has already implemented and registered, then developer
> knows at the first place.
>
> Suggested-by: Alexei Starovoitov <alexei.starovoitov@gmail.com>
> Suggested-by: Kaitao Cheng <kaitao.cheng@linux.dev>
> Signed-off-by: Song Chen <chensong_2000@126.com>
>
> ---
> changelog:
> v1 --- v2:
> libbpf has already specified which module this kfunc belongs to as
> ebpf code onwer's expectation, then verifier uses
> find_kallsyms_symbol_value to search kfunc's addr.
>
> v2 --- v3:
> After v2, I tried a new idea of introducing a namespace in libbpf
> to specify kfunc owner in an ebpf program suggested by Kaitao Cheng,
> please see [1]. Alex suggested to go back to report an error during
> kmod load on conflicting kfunc name for now. What's more, v2 only
> searched bpf_vmlinux, v3 also traverses btf_modules list.
>
> [1]:https://lore.kernel.org/all/CAADnVQ+jYGMjAC9aNygmhyppUO9foWN4z9cjSpwCEXAFHpRVJQ@mail.gmail.com/
> ---
> kernel/bpf/btf.c | 44 +++++++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 43 insertions(+), 1 deletion(-)
>
btf: reject to register duplicated kfunc
> diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
> index 4872d2a6c42d..a14ad3720872 100644
> --- a/kernel/bpf/btf.c
> +++ b/kernel/bpf/btf.c
> @@ -8618,6 +8618,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;
This ret variable may be unnecessary.
> +
> + if (!btf_is_module(btf))
> + goto out;
> +
> + id = btf_find_by_name_kind(bpf_get_btf_vmlinux(),
> + func_name, kind);
It seems unnecessary to split this call across multiple lines. Also,
some of the continuation-line indentation elsewhere does not appear
to follow the kernel coding style.
> + if (id >= 0) {
> + pr_err("kfunc %s (id: %d) is already present in vmlinux.\n",
> + func_name, id);
> + ret = -EINVAL;
> + goto out;
return -EINVAL;
> + }
> +
> +#ifdef CONFIG_DEBUG_INFO_BTF_MODULES
> + mutex_lock(&btf_module_mutex);
> + list_for_each_entry_safe(btf_mod, tmp, &btf_modules, list) {
> + if (btf_mod->btf == btf)
> + continue;
> + id = btf_find_by_name_kind(btf_mod->btf,
> + func_name, kind);
> + if (id >= 0) {
> + pr_err("kfunc %s (id: %d) is already present in module %s.\n",
> + func_name, id, btf_mod->module->name);
follow the kernel coding style
> + ret = -EINVAL;
> + break;
mutex_unlock(&btf_module_mutex);
return -EINVAL;
> + }
> + }
> + mutex_unlock(&btf_module_mutex);
> +#endif
> +
> +out:
> + return ret;
> +}
> +
> static int btf_check_kfunc_protos(struct btf *btf, u32 func_id, u32 func_flags)
> {
> const struct btf_type *func;
> @@ -8631,7 +8672,8 @@ static int btf_check_kfunc_protos(struct btf *btf, u32 func_id, u32 func_flags)
>
> /* sanity check kfunc name */
> func_name = btf_name_by_offset(btf, func->name_off);
> - if (!func_name || !func_name[0])
> + if (!func_name || !func_name[0]
> + || btf_check_kfunc_name(btf, func_name, BTF_INFO_KIND(func->info)))
follow the kernel coding style
> return -EINVAL;
>
> func = btf_type_by_id(btf, func->type);
--
Thanks
Kaitao Cheng
next prev parent reply other threads:[~2026-05-25 9:20 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-24 8:29 [PATCH v3] kernel/bpf/btf.c: reject to register duplicated kfunc Song Chen
2026-05-24 9:10 ` sashiko-bot
2026-05-24 9:38 ` Alexei Starovoitov
2026-05-24 9:15 ` bot+bpf-ci
2026-05-24 9:42 ` Alexei Starovoitov
2026-05-25 7:47 ` Song Chen
2026-05-25 9:18 ` Kaitao Cheng [this message]
2026-05-29 3:01 ` Alexei Starovoitov
2026-06-01 9:23 ` Song Chen
2026-06-01 9:21 ` Song Chen
2026-06-01 9:39 ` Song Chen
2026-06-01 16:09 ` Yonghong Song
2026-06-02 11:01 ` 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=757e24eb-45d3-4e05-9aa2-f077bec8fea9@linux.dev \
--to=kaitao.cheng@linux.dev \
--cc=alexei.starovoitov@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=chensong_2000@126.com \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=haoluo@google.com \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.