Re: [PATCH v2 3/3] libbpf: plumb btf_vmlinux_value_type_id and btf_fd in gen_loader

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The patch incorrectly reduces `attr_size` when constructing the BPF map creation attributes, silently truncating and discarding the `map_extra` field.
--

commit 72a5ab975182d8bdeec79a02a460190b45ceeb56
Author: Siddharth Nayyar <sidnayyar@google.com>

libbpf: plumb btf_vmlinux_value_type_id and btf_fd in gen_loader

This commit updates the gen_loader map creation logic to include
btf_vmlinux_value_type_id and conditionally copy the loaded btf_fd into
the BPF attributes blob. It also alters the attr_size calculation based
on an assumption about the layout of union bpf_attr.

>     Previously, the `gen_loader` map creation generator
>     (`bpf_gen__map_create()`) completely omitted plumbing
>     `btf_vmlinux_value_type_id` because `attr_size` was calculated only up
>     to `map_extra` (which resides before `btf_vmlinux_value_type_id` in
>     `union bpf_attr`).

[Severity: High]
Is this description accurate regarding the layout of union bpf_attr?

Looking at the structure layout, map_extra is actually located immediately
after btf_vmlinux_value_type_id, not before it.

> diff --git a/tools/lib/bpf/gen_loader.c b/tools/lib/bpf/gen_loader.c
> index cd5c2543f54d8..27b0353d1082e 100644
> --- a/tools/lib/bpf/gen_loader.c
> +++ b/tools/lib/bpf/gen_loader.c
> @@ -507,7 +507,7 @@ void bpf_gen__map_create(struct bpf_gen *gen,
>  			 __u32 key_size, __u32 value_size, __u32 max_entries,
>  			 struct bpf_map_create_opts *map_attr, int map_idx)
>  {
> -	int attr_size = offsetofend(union bpf_attr, map_extra);
> +	int attr_size = offsetofend(union bpf_attr, btf_vmlinux_value_type_id);

[Severity: High]
Does this change silently truncate the map_extra field from the generated
system call arguments?

Since map_extra actually follows btf_vmlinux_value_type_id in union bpf_attr,
reducing attr_size to offsetofend(..., btf_vmlinux_value_type_id) completely
strips map_extra from the payload.

When add_data() copies attr_size bytes, the kernel will subsequently assume
map_extra is 0. This seems like it would break functionality for maps that
rely on map_extra when loaded via light skeletons, such as BPF_MAP_TYPE_ARENA
(where it represents the mmap address) and BPF_MAP_TYPE_BLOOM_FILTER (where
it specifies the number of hash functions).

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260526-libbpf-load-vmlinux-btf-in-gen_loader-mode-v2-0-6750f5859bc6@google.com?part=3