Re: [PATCH v4 2/3] libbpf: zero out btf_key_type_id for STRUCT_OPS maps

[bot+bpf-ci]

> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> index 420d37f215ea..673fa0242b4c 100644
> --- a/tools/lib/bpf/libbpf.c
> +++ b/tools/lib/bpf/libbpf.c
> @@ -5440,6 +5440,7 @@ static int bpf_object__create_map(struct bpf_object *obj, struct bpf_map *map, b
>  		map->btf_value_type_id = 0;
>  		break;
>  	case BPF_MAP_TYPE_STRUCT_OPS:
> +		create_attr.btf_key_type_id = 0;
>  		create_attr.btf_value_type_id = 0;
>  		break;
>  	default:

This change fixes the issue in bpf_object__create_map(), but what about
gen_loader mode?

In bpf_gen__map_create() (tools/lib/bpf/gen_loader.c), when
btf_vmlinux_value_type_id is set for STRUCT_OPS maps, it's not copied
to the attr structure:

    attr.btf_key_type_id = tgt_endian(map_attr->btf_key_type_id);
    attr.btf_value_type_id = tgt_endian(map_attr->btf_value_type_id);
    /* btf_vmlinux_value_type_id is never copied */

This means gen_loader mode (light skeletons) will pass
btf_vmlinux_value_type_id=0 to the kernel, breaking STRUCT_OPS map
creation. Does this need to be addressed?

Also, the conditional that copies btf_fd in bpf_gen__map_create():

    if (map_attr->btf_value_type_id)
        move_stack2blob(gen, attr_field(map_create_attr, btf_fd), 4,
                        stack_off(btf_fd));

This condition evaluates to false for STRUCT_OPS maps since
btf_value_type_id is now explicitly zeroed. Won't this prevent
btf_fd from being copied to the kernel attributes?

The kernel expects a valid btf_fd even for STRUCT_OPS maps (see
kernel/bpf/syscall.c comments: "Even the map's value is a kernel's
struct, the bpf_prog.o must have BTF to begin with to figure out
the corresponding kernel's counter part."). Without btf_fd,
btf_get_by_fd(0) will fail.

It looks like both of these issues are fixed in the next commit
(fe6415fcc857b593808826b2e8d157237162782b), but should they be addressed
in this patch to avoid bisection breakage?

Regarding the commit message:

> libbpf: zero out btf_key_type_id for STRUCT_OPS maps
>
> For BPF `STRUCT_OPS` maps (such as `sched_ext_ops` maps), the kernel BPF
> subsystem enforces strict map-creation safety validations inside
> `map_create()`.  That is, if `btf_vmlinux_value_type_id` is set, the
> kernel forbids passing any userspace `btf_key_type_id` or
> `btf_value_type_id` (they must both be `0`).
>
> However, inside libbpf's map-creation options initialization
> (`bpf_object__create_map()`), libbpf zeroed out
> `create_attr.btf_value_type_id` but does not zero out
> `create_attr.btf_key_type_id`.
>
> Fix this by explicitly zeroing out `create_attr.btf_key_type_id`.
>
> Signed-off-by: Siddharth Nayyar <sidnayyar@xxxxxxxxxx>

This looks like a bug fix but lacks a Fixes: tag. The bug was
introduced when STRUCT_OPS support was added to libbpf. Should this
include:

  Fixes: 590a00888250 ("bpf: libbpf: Add STRUCT_OPS support")

Also, Alexei Starovoitov requested a selftest in v3 of the patch series:

  "The selftest is mandatory to prove that."

  https://lore.kernel.org/bpf/CAADnVQ+AA_fmRw7uRwdL2TMyMbpWeebOQKb=0wvpKiQR6Ee5xQ@xxxxxxxxxxxxxx/

Has this been addressed in v4? Without a selftest proving that
STRUCT_OPS maps work correctly in light skeleton mode, how can we
verify the fix is complete?


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