Re: [PATCH] kernel/bpf/btf.c: reject to register duplicated kfunc

[Song Chen <chensong_2000@189.cn>]

hi,

在 2026/1/21 10:16, bot+bpf-ci@kernel.org 写道:
>> diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
>> index d10b3404260f..b4ded7669642 100644
>> --- a/kernel/bpf/btf.c
>> +++ b/kernel/bpf/btf.c
>> @@ -8615,12 +8615,23 @@ static int btf_check_iter_kfuncs(struct btf *btf, const char *func_name,
>>   	return 0;
>>   }
>>
>> -static int btf_check_kfunc_protos(struct btf *btf, u32 func_id, u32 func_flags)
>> +static int btf_check_kfunc_protos(struct btf *btf, u32 func_id, u32 func_flags,
>> +			const struct module *module)
>>   {
>>   	const struct btf_type *func;
>>   	const char *func_name;
>>   	int err;
>>
>> +	/* check if there is any duplicated kfunc in vmlinux */
>> +	if (module) {
>> +		func = btf_type_by_id(btf_vmlinux, func_id);
> 
> The func_id parameter comes from the module's BTF (via btf_relocate_id),
> but this code looks it up in btf_vmlinux. BTF type IDs are specific to
> each BTF - vmlinux and modules have independent ID namespaces.
> 
> Is this lookup correct? btf_type_by_id(btf_vmlinux, func_id) will return
> whatever type happens to be at that numeric ID in vmlinux, not the type
> with the same name as the module's kfunc. For example, if the module's
> kfunc has BTF ID 100, this returns vmlinux type ID 100, which is likely
> an unrelated struct or typedef.
> 
> This seems like it would cause false positives - any module kfunc
> registration would fail if its BTF ID happens to fall within vmlinux's
> BTF ID range (vmlinux typically has tens of thousands of types).
> 
> To detect duplicate names, shouldn't this use btf_find_by_name_kind()
> to search by the function name instead of btf_type_by_id()?

The namespace has come up to my mind at the first place, i dumped kfunc 
info from btf_vmlinux and my module, turned out, they had same btf id:

[  114.348494] Hello, world!, id:150090
[  114.348499] dump_btf_info, btf name:hello, btf 
addr:0xffff8bc468c0bb00, nr_types:153081
[  115.709254] BTF ID 150090:
[  115.709255]   name_off: 2480470
[  115.709259]   name: bpf_strstr
[  115.709259]   kind: 12 (FUNC)
[  115.709260]   type_id: 150066
[  115.709260]   addr: 0xffffffffa93f9f50
[  115.720383] BTF ID 153075:
[  115.720384]   name_off: 2480470
[  115.720384]   name: bpf_strstr
[  115.720385]   kind: 12 (FUNC)
[  115.720385]   type_id: 153074
[  115.720385]   addr: 0xffffffffa93f9f50
[  115.720397] dump_btf_info, btf name:vmlinux, btf 
addr:0xffff8bc446112000, nr_types:153074
[  117.067793] BTF ID 150090:
[  117.067794]   name_off: 2480470
[  117.067794]   name: bpf_strstr
[  117.067795]   kind: 12 (FUNC)
[  117.067796]   type_id: 150066
[  117.067796]   addr: 0xffffffffa93f9f50
[  117.078950] bpf_kfunc_example: Module loaded successfully

Is this a coincidence? I couldn't help but think btf_id is a global 
value. If you have been trained with this kind of knowledge, i would
appreciate it if you could explain.

Nevertheless, btf_find_by_name_kind is a more reasonable way to 
approach, i will submit v2 to review.

many thanks

/Song

> 
>> +		if (func) {
>> +			pr_err("kfunc %s is already present in vmlinux\n",
>> +						btf_name_by_offset(btf_vmlinux, func->name_off));
> 
> Since func is an unrelated vmlinux type (not the module's kfunc), this
> error message prints the wrong function name - it shows whatever random
> vmlinux type was found at that ID, not the module's kfunc name.
> 
>> +			return -EINVAL;
>> +		}
>> +	}
> 
> [ ... ]
> 
>> @@ -8911,7 +8922,7 @@ static int __register_btf_kfunc_id_set(enum btf_kfunc_hook hook,
>>
>>   	for (i = 0; i < kset->set->cnt; i++) {
>>   		ret = btf_check_kfunc_protos(btf, btf_relocate_id(btf, kset->set->pairs[i].id),
>> -					     kset->set->pairs[i].flags);
>> +					     kset->set->pairs[i].flags, kset->owner);
> 
> This shows that func_id passed to btf_check_kfunc_protos is from the
> module's BTF (btf_relocate_id operates on the module's btf), confirming
> the namespace mismatch when it gets looked up in btf_vmlinux above.
> 
>>   		if (ret)
>>   			goto err_out;
>>   	}
> 
> 
> ---
> AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
> See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
> 
> CI run summary: https://github.com/kernel-patches/bpf/actions/runs/21194595610