Re: [PATCH RFC bpf-next 3/7] libbpf: Support BPF_MAP_TYPE_STRUCT_OPS in bpf_gen__map_create()

[bot+bpf-ci]

> libbpf: Support BPF_MAP_TYPE_STRUCT_OPS in bpf_gen__map_create()

TL;DR: In bpf_gen__map_create(), the struct_ops module BTF fd is closed only
after BPF_MAP_CREATE, so earlier loader failures may leak that fd, and a
retrying daemon may leak one per attempt.

> diff --git a/tools/lib/bpf/gen_loader.c b/tools/lib/bpf/gen_loader.c
> --- a/tools/lib/bpf/gen_loader.c
> +++ b/tools/lib/bpf/gen_loader.c

[ ... ]

> @@ -568,6 +589,9 @@ void bpf_gen__map_create(struct bpf_gen *gen,
>  	debug_ret(gen, "map_create %s idx %d type %d value_size %d value_btf_id %d",
>  		  map_name, map_idx, map_type, value_size,
>  		  map_attr->btf_value_type_id);
> +	if (map_type == BPF_MAP_TYPE_STRUCT_OPS)
> +		emit_sys_close_blob(gen,
> +				    attr_field(map_create_attr, value_type_btf_obj_fd));
>  	emit_check_err(gen);

The module BTF fd is only closed here, on the BPF_MAP_CREATE path of this
map.  Is it possible for the loader to leak that fd on earlier failures?

The fd is opened by the code emitted from bpf_gen__init_kern_struct_ops(),
which runs before bpf_object__sanitize_and_load_btf() and
bpf_object__create_maps().  Between those points the loader has several
emit_check_err() jumps to the cleanup label, for example:

  bpf_gen__load_btf()
  an earlier map's BPF_MAP_CREATE
  the struct_ops init sequence checks for a second module struct_ops map

The cleanup code emitted by bpf_gen__init() closes only btf_fd,
inner_map_fd, prog_fd[] and the first nr_maps fd_array entries, so the fd
stored in the upper 32 bits of the vtype_id_off slot is never closed on
those paths.

If one of those steps fails, a module BTF fd stays open in the process that
ran the loader, and a daemon that retries the load leaks one more fd each
time.  bpf_gen__prog_load() closes its module BTF fds "successful or not"
before any error jump.

Could the vtype btf fd also be closed on the cleanup path, or be kept
somewhere the cleanup code already closes?


---
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/42289585064