[PATCH bpf] libbpf: fix log level propagation for light skeleton loaders

[PATCH bpf] libbpf: fix log level propagation for light skeleton loaders

[Mahe Tardy]

bpftool's -d option is documented to enable bpf_trace_printk() messages
from the generated syscall loader when used with -L as specified in
commit d510296d331a ("bpftool: Use syscall/loader program in "prog load"
and "gen skeleton" command.")

However commit b59e4ce8bcaa ("bpftool: Switch bpf_object__load_xattr()
to bpf_object__load()") changed bpftool to use bpf_object__load() which
call the internal bpf_object_load with extra_log_level to 0 instead of
bpf_object__load_xattr with the user request log_level.

All the plumbing was still there to generate the bpf_trace_printk()
instructions from the generator but was now unreachable because
bpf_gen__init() was called with extra_log_level to 0, leaving
gen->log_level at 0.

This uses the obj->log_level field introduced in commit e0e3ea888c69
("libbpf: Allow passing user log setting through bpf_object_open_opts")
set from reading verifier_logs in do_skeleton(). This preserves both
object-level and explicit load-time logging settings.

Fixes: b59e4ce8bcaa ("bpftool: Switch bpf_object__load_xattr() to bpf_object__load()")
Signed-off-by: Mahe Tardy <mahe.tardy@gmail.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 c036e8a91ed8..395c4dcb54de 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -9144,7 +9144,8 @@ static int bpf_object_load(struct bpf_object *obj, int extra_log_level, const ch
 	 * permit cross-endian creation of "light skeleton".
 	 */
 	if (obj->gen_loader) {
-		bpf_gen__init(obj->gen_loader, extra_log_level, obj->nr_programs, obj->nr_maps);
+		bpf_gen__init(obj->gen_loader, obj->log_level | extra_log_level,
+			      obj->nr_programs, obj->nr_maps);
 	} else if (!is_native_endianness(obj)) {
 		pr_warn("object '%s': loading non-native endianness is unsupported\n", obj->name);
 		return libbpf_err(-LIBBPF_ERRNO__ENDIAN);
--
2.34.1

Re: [PATCH bpf] libbpf: fix log level propagation for light skeleton loaders

[Mahe Tardy]

On Fri, Sep 04, 2026 at 05:16:01PM +0000, Mahe Tardy wrote:
> bpftool's -d option is documented to enable bpf_trace_printk() messages
> from the generated syscall loader when used with -L as specified in
> commit d510296d331a ("bpftool: Use syscall/loader program in "prog load"
> and "gen skeleton" command.")
> 
> However commit b59e4ce8bcaa ("bpftool: Switch bpf_object__load_xattr()
> to bpf_object__load()") changed bpftool to use bpf_object__load() which
> call the internal bpf_object_load with extra_log_level to 0 instead of
> bpf_object__load_xattr with the user request log_level.
> 
> All the plumbing was still there to generate the bpf_trace_printk()
> instructions from the generator but was now unreachable because
> bpf_gen__init() was called with extra_log_level to 0, leaving
> gen->log_level at 0.
> 
> This uses the obj->log_level field introduced in commit e0e3ea888c69
> ("libbpf: Allow passing user log setting through bpf_object_open_opts")
> set from reading verifier_logs in do_skeleton(). This preserves both
> object-level and explicit load-time logging settings.
> 
> Fixes: b59e4ce8bcaa ("bpftool: Switch bpf_object__load_xattr() to bpf_object__load()")
> Signed-off-by: Mahe Tardy <mahe.tardy@gmail.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 c036e8a91ed8..395c4dcb54de 100644
> --- a/tools/lib/bpf/libbpf.c
> +++ b/tools/lib/bpf/libbpf.c
> @@ -9144,7 +9144,8 @@ static int bpf_object_load(struct bpf_object *obj, int extra_log_level, const ch
>  	 * permit cross-endian creation of "light skeleton".
>  	 */
>  	if (obj->gen_loader) {
> -		bpf_gen__init(obj->gen_loader, extra_log_level, obj->nr_programs, obj->nr_maps);
> +		bpf_gen__init(obj->gen_loader, obj->log_level | extra_log_level,
> +			      obj->nr_programs, obj->nr_maps);
>  	} else if (!is_native_endianness(obj)) {
>  		pr_warn("object '%s': loading non-native endianness is unsupported\n", obj->name);
>  		return libbpf_err(-LIBBPF_ERRNO__ENDIAN);
> --
> 2.34.1

I realized after sending that writing a regression test wouldn't be too
complicated since we can check for missing instructions in the loader
program given some user input. Tell me if that would be useful or not
for such a small fix.

> 

Re: [PATCH bpf] libbpf: fix log level propagation for light skeleton loaders

[Daniel Borkmann]

On 9/4/26 8:12 PM, Mahe Tardy wrote:
> On Fri, Sep 04, 2026 at 05:16:01PM +0000, Mahe Tardy wrote:
>> bpftool's -d option is documented to enable bpf_trace_printk() messages
>> from the generated syscall loader when used with -L as specified in
>> commit d510296d331a ("bpftool: Use syscall/loader program in "prog load"
>> and "gen skeleton" command.")
>>
>> However commit b59e4ce8bcaa ("bpftool: Switch bpf_object__load_xattr()
>> to bpf_object__load()") changed bpftool to use bpf_object__load() which
>> call the internal bpf_object_load with extra_log_level to 0 instead of
>> bpf_object__load_xattr with the user request log_level.
>>
>> All the plumbing was still there to generate the bpf_trace_printk()
>> instructions from the generator but was now unreachable because
>> bpf_gen__init() was called with extra_log_level to 0, leaving
>> gen->log_level at 0.
>>
>> This uses the obj->log_level field introduced in commit e0e3ea888c69
>> ("libbpf: Allow passing user log setting through bpf_object_open_opts")
>> set from reading verifier_logs in do_skeleton(). This preserves both
>> object-level and explicit load-time logging settings.
>>
>> Fixes: b59e4ce8bcaa ("bpftool: Switch bpf_object__load_xattr() to bpf_object__load()")
>> Signed-off-by: Mahe Tardy <mahe.tardy@gmail.com>

Acked-by: Daniel Borkmann <daniel@iogearbox.net>

> I realized after sending that writing a regression test wouldn't be too
> complicated since we can check for missing instructions in the loader
> program given some user input. Tell me if that would be useful or not
> for such a small fix.
It might probably make sense for bpf-next to craft a BPF selftest for
lsekl loader in general to test out all kind of corner/failure cases for
correctness. signed_loader does a bit but its not exhaustive and could
be a dedicated test.