Re: [PATCH v3] kernel/bpf/btf.c: reject to register duplicated kfunc
From: Song Chen
Date: Mon Jun 01 2026 - 05:26:04 EST
Hi,
在 2026/5/25 17:18, Kaitao Cheng 写道:
在 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@xxxxxxxxx>
Suggested-by: Kaitao Cheng <kaitao.cheng@xxxxxxxxx>
Signed-off-by: Song Chen <chensong_2000@xxxxxxx>
---
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@xxxxxxxxxxxxxx/
---
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);
will do, thanks so much.
Song