[PATCH bpf-next] libbpf: Ignore the modules that failed to load BTF object

[PATCH bpf-next] libbpf: Ignore the modules that failed to load BTF object

[Bixuan Cui]

Register kfunc in self-developed module but run error in other modules:
    libbpf: btf: type [164451]: referenced type [164446] is not FUNC_PROTO
    libbpf: failed to load module [syscon_reboot_mode]'s BTF object #2: -22

It is usually skipping the error does not affect the search for the next module.

Then ignoring the failed modules, load the bpf process:
    libbpf: btf: type [164451]: referenced type [164446] is not FUNC_PROTO
    libbpf: failed to load module [syscon_reboot_mode]'s BTF object #3: -22
    libbpf: extern (func ksym) 'bpf_kfunc': resolved to bpf_module [164442]
    ...

Signed-off-by: Bixuan Cui <cuibixuan@vivo.com>
---
 tools/lib/bpf/libbpf.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index 711173acbcef..0fa0d89da068 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -5702,7 +5702,8 @@ static int load_module_btfs(struct bpf_object *obj)
 		if (err) {
 			pr_warn("failed to load module [%s]'s BTF object #%d: %d\n",
 				name, id, err);
-			goto err_out;
+			close(fd);
+			continue;
 		}

 		err = libbpf_ensure_mem((void **)&obj->btf_modules, &obj->btf_module_cap,
--
2.39.0

Re: [PATCH bpf-next] libbpf: Ignore the modules that failed to load BTF object

[Andrii Nakryiko]

On Tue, Oct 28, 2025 at 6:57 AM Bixuan Cui <cuibixuan@vivo.com> wrote:
>
> Register kfunc in self-developed module but run error in other modules:
>     libbpf: btf: type [164451]: referenced type [164446] is not FUNC_PROTO
>     libbpf: failed to load module [syscon_reboot_mode]'s BTF object #2: -22
>
> It is usually skipping the error does not affect the search for the next module.
>
> Then ignoring the failed modules, load the bpf process:
>     libbpf: btf: type [164451]: referenced type [164446] is not FUNC_PROTO
>     libbpf: failed to load module [syscon_reboot_mode]'s BTF object #3: -22
>     libbpf: extern (func ksym) 'bpf_kfunc': resolved to bpf_module [164442]
>     ...
>
> Signed-off-by: Bixuan Cui <cuibixuan@vivo.com>
> ---
>  tools/lib/bpf/libbpf.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> index 711173acbcef..0fa0d89da068 100644
> --- a/tools/lib/bpf/libbpf.c
> +++ b/tools/lib/bpf/libbpf.c
> @@ -5702,7 +5702,8 @@ static int load_module_btfs(struct bpf_object *obj)
>                 if (err) {
>                         pr_warn("failed to load module [%s]'s BTF object #%d: %d\n",
>                                 name, id, err);
> -                       goto err_out;
> +                       close(fd);
> +                       continue;
>                 }

It's not an expected condition to have kernel module with corrupted
BTF, so I don't think we should be doing this.

pw-bot: cr


>
>                 err = libbpf_ensure_mem((void **)&obj->btf_modules, &obj->btf_module_cap,
> --
> 2.39.0
>

Re: [PATCH bpf-next] libbpf: Ignore the modules that failed to load BTF object

[Alan Maguire]

On 28/10/2025 18:05, Andrii Nakryiko wrote:
> On Tue, Oct 28, 2025 at 6:57 AM Bixuan Cui <cuibixuan@vivo.com> wrote:
>>
>> Register kfunc in self-developed module but run error in other modules:
>>     libbpf: btf: type [164451]: referenced type [164446] is not FUNC_PROTO
>>     libbpf: failed to load module [syscon_reboot_mode]'s BTF object #2: -22
>>
>> It is usually skipping the error does not affect the search for the next module.
>>
>> Then ignoring the failed modules, load the bpf process:
>>     libbpf: btf: type [164451]: referenced type [164446] is not FUNC_PROTO
>>     libbpf: failed to load module [syscon_reboot_mode]'s BTF object #3: -22
>>     libbpf: extern (func ksym) 'bpf_kfunc': resolved to bpf_module [164442]
>>     ...
>>
>> Signed-off-by: Bixuan Cui <cuibixuan@vivo.com>
>> ---
>>  tools/lib/bpf/libbpf.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
>> index 711173acbcef..0fa0d89da068 100644
>> --- a/tools/lib/bpf/libbpf.c
>> +++ b/tools/lib/bpf/libbpf.c
>> @@ -5702,7 +5702,8 @@ static int load_module_btfs(struct bpf_object *obj)
>>                 if (err) {
>>                         pr_warn("failed to load module [%s]'s BTF object #%d: %d\n",
>>                                 name, id, err);
>> -                       goto err_out;
>> +                       close(fd);
>> +                       continue;
>>                 }
> 
> It's not an expected condition to have kernel module with corrupted
> BTF, so I don't think we should be doing this.
> 
> pw-bot: cr
>

Would be good to understand this failure better. If the module is being
built out-of-tree with relatively new pahole, it will have a .BTF.base
section and a .BTF section; the .BTF.base section allows the module to
carry stable references to vmlinux BTF types which then get fixed up to
the real vmlinux BTF id references when the module is loaded. It is
possible there are bugs in that code however, so it woul be good to
figure that out. bpftool should dump BTF for your module using the
.BTF.base section as base, so

bpftool btf dump file mymod.ko

should work (provided "objdump -h mymod.ko" shows a .BTF.base and .BTF
section).  If it does, the BTF id relocation may be breaking and we
might need to do further digging to understand where. It should relocate
BTF kfunc ids also, but again there may be a bug lurking here.

If the BTF is loading into the kernel, comparing

bpftool btf dump -B /sys/kernel/btf file /sys/kernel/btf/mymod

...to the .ko BTF would be valuable.

If your module only has a .BTF section and no .BTF.base section, it is
possible it did not get (re)built against an updated vmlinux and has
outdated type id references as a result.

Alan

Re: [PATCH bpf-next] libbpf: Ignore the modules that failed to load BTF object

[Bixuan Cui]

在 2025/10/29 2:21, Alan Maguire 写道:
>> It's not an expected condition to have kernel module with corrupted
>> BTF, so I don't think we should be doing this.
>>
>> pw-bot: cr
>>
> Would be good to understand this failure better. If the module is being
> built out-of-tree with relatively new pahole, it will have a .BTF.base
> section and a .BTF section; the .BTF.base section allows the module to
> carry stable references to vmlinux BTF types which then get fixed up to
> the real vmlinux BTF id references when the module is loaded. It is
> possible there are bugs in that code however, so it woul be good to
> figure that out. bpftool should dump BTF for your module using the
> .BTF.base section as base, so
> 
> bpftool btf dump file mymod.ko
> 
> should work (provided "objdump -h mymod.ko" shows a .BTF.base and .BTF
> section).  If it does, the BTF id relocation may be breaking and we
> might need to do further digging to understand where. It should relocate
> BTF kfunc ids also, but again there may be a bug lurking here.
> 
> If the BTF is loading into the kernel, comparing
> 
> bpftool btf dump -B /sys/kernel/btf file /sys/kernel/btf/mymod
> 
> ...to the .ko BTF would be valuable.
> 
> If your module only has a .BTF section and no .BTF.base section, it is
> possible it did not get (re)built against an updated vmlinux and has
> outdated type id references as a result.
Thank you, I will first look at the error reported by this module.

Bixuan Cui