Re: [PATCH bpf-next 2/2] bpftool: Reject non-autoload programs for light skeletons

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Direct return on the error path for non-autoload programs leaks the file descriptor, memory mapping, and BPF object.
--

commit 2f23ddc68c8f556d1272e5244820c6008be97512
Author: Thiébaud Weksteen <tweek@google.com>

bpftool: Reject non-autoload programs for light skeletons
    
When generating a light skeleton (bpftool gen skeleton -L), there is no
libbpf runtime object or bpf_program__set_autoload() API available to
enable/disable the autoloading of programs. This commit explicitly rejects
non-autoloaded programs when use_loader is true with an error message to
prevent generating broken light skeleton headers.

> diff --git a/tools/bpf/bpftool/gen.c b/tools/bpf/bpftool/gen.c
> index a50540ef6521c..1583150241c88 100644
> --- a/tools/bpf/bpftool/gen.c
> +++ b/tools/bpf/bpftool/gen.c
> @@ -1340,6 +1340,12 @@ static int do_skeleton(int argc, char **argv)
>  	}
>  	bpf_object__for_each_program(prog, obj) {
>  		prog_cnt++;
> +
> +		if (use_loader && !bpf_program__autoload(prog)) {
> +			p_err("program '%s' is marked as non-autoload, which is not supported for light skeletons",
> +			      bpf_program__name(prog));
> +			return -1;

[Severity: Low]
Does this code leak the file descriptor, memory mapping, and BPF object?

Since this returns directly, it bypasses the established resource cleanup block
(the out: and out_obj: labels) at the end of do_skeleton(), which would
normally call bpf_object__close(obj), munmap(obj_data, mmap_sz), and close(fd).

Could this set err = -1 and use goto out; instead?

> +		}
>  	}
>  
>  	get_header_guard(header_guard, obj_name, "SKEL_H");

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260904031912.2133476-1-tweek@google.com?part=2