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

[Mahe Tardy <mahe.tardy@gmail.com>]

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.

>