[PATCH v3 0/3] libbpf: support STRUCT_OPS in light skeletons

[PATCH v3 0/3] libbpf: support STRUCT_OPS in light skeletons

[Siddharth Nayyar]

This series enables support for BPF `STRUCT_OPS` maps (such as
`sched_ext_ops` used by sched_ext) when using light skeletons (i.e.
`gen_loader` mode).

Previously, generating light skeletons for objects containing
`STRUCT_OPS` maps would fail or produce incomplete results because
`gen_loader` lacked support for several key features required by
`STRUCT_OPS` maps, specifically:

1. Loading `vmlinux` BTF to resolve kernel-side type information.
2. Correctly plumbing `btf_vmlinux_value_type_id` into map creation
   attributes.
3. Ensuring `btf_key_type_id` is zeroed out to satisfy kernel safety
   checks.
4. Plumbing the userspace BTF FD (`btf_fd`) when
   `btf_vmlinux_value_type_id` is present but `btf_value_type_id` is
   zero (which is always the case for `STRUCT_OPS` maps).

This series addresses these limitations by:

- Loading `vmlinux` BTF in `gen_loader` mode when the BPF object
  contains `struct_ops` maps.
- Explicitly zeroing out `btf_key_type_id` for `STRUCT_OPS` maps to
  satisfy kernel validations.
- Plumbing `btf_vmlinux_value_type_id` during map creation in
  `gen_loader`.
- Fixing `btf_fd` copying logic in `gen_loader` to populate it if either
  `btf_value_type_id` or `btf_vmlinux_value_type_id` is set.

With these changes, it is now possible to generate and use light
skeletons for BPF programs utilizing `STRUCT_OPS`, such as custom
sched_ext schedulers.

Signed-off-by: Siddharth Nayyar <sidnayyar@google.com>
---
Changes in v3:
- Remove erroneous change contracting map creation attribute size in gen_loader.
- Link to v2: https://lore.kernel.org/r/20260526-libbpf-load-vmlinux-btf-in-gen_loader-mode-v2-0-6750f5859bc6@google.com

Changes in v2:
- Expand the series to 3 patches to fully support STRUCT_OPS in gen_loader.
- Add a patch to explicitly zero out btf_key_type_id for STRUCT_OPS maps.
- Add a patch to plumb btf_vmlinux_value_type_id and btf_fd in gen_loader.
- Link to v1: https://lore.kernel.org/r/20260524-libbpf-load-vmlinux-btf-in-gen_loader-mode-v1-1-6f57f191a7ad@google.com

---
Siddharth Nayyar (3):
      libbpf: load vmlinux BTF in gen_loader mode for struct_ops
      libbpf: zero out btf_key_type_id for STRUCT_OPS maps
      libbpf: plumb btf_vmlinux_value_type_id and btf_fd in gen_loader

 tools/lib/bpf/gen_loader.c | 3 ++-
 tools/lib/bpf/libbpf.c     | 6 +++++-
 2 files changed, 7 insertions(+), 2 deletions(-)
---
base-commit: c6e99c10fd9855082568cbd71bb2cc5dc90eda53
change-id: 20260522-libbpf-load-vmlinux-btf-in-gen_loader-mode-4474834aa467

Best regards,
-- 
Siddharth Nayyar <sidnayyar@google.com>

[PATCH v3 1/3] libbpf: load vmlinux BTF in gen_loader mode for struct_ops

[Siddharth Nayyar]

During light skeleton generation (`bpftool gen skeleton -L`), libbpf
runs in gen_loader mode. Previously, `bpf_object__load_vmlinux_btf()`
completely bypassed loading the kernel vmlinux BTF (`obj->btf_vmlinux`)
if `gen_loader` was active.

However, BPF `struct_ops` maps (such as `sched_ext_ops` maps) require
resolving the kernel-side struct type IDs and member sizes at
compile/skeleton generation time. Without loading `btf_vmlinux`, libbpf
cannot query the kernel BTF types, causing light skeleton generation for
`struct_ops` to fail or omit crucial type information.

Fix this by modifying the check to load `btf_vmlinux` even in
`gen_loader` mode if the BPF object actually requires kernel vmlinux BTF
(e.g. contains `struct_ops` maps).

Signed-off-by: Siddharth Nayyar <sidnayyar@google.com>
---
 tools/lib/bpf/libbpf.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index 3a80a018fc7d..cb1b7ea884a7 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -3590,7 +3590,10 @@ static int bpf_object__load_vmlinux_btf(struct bpf_object *obj, bool force)
 	int err;
 
 	/* btf_vmlinux could be loaded earlier */
-	if (obj->btf_vmlinux || obj->gen_loader)
+	if (obj->btf_vmlinux)
+		return 0;
+
+	if (obj->gen_loader && !obj_needs_vmlinux_btf(obj))
 		return 0;
 
 	if (!force && !obj_needs_vmlinux_btf(obj))

-- 
2.54.0.746.g67dd491aae-goog

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

[Siddharth Nayyar]

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@google.com>
---
 tools/lib/bpf/libbpf.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index cb1b7ea884a7..9969de42da41 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -5439,6 +5439,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:

-- 
2.54.0.746.g67dd491aae-goog

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

[Siddharth Nayyar]

BPF `STRUCT_OPS` maps (such as `sched_ext_ops` maps) require resolving
and plumbing the kernel-side structure value type ID
(`btf_vmlinux_value_type_id`) into the BPF map creation system call
attributes. Additionally, when `btf_vmlinux_value_type_id` is supplied,
the kernel requires a valid userspace BTF file descriptor (`btf_fd`) to
be supplied to verify types.

Previously, the `gen_loader` map creation generator
(`bpf_gen__map_create()`) omitted plumbing `btf_vmlinux_value_type_id`.
Furthermore, `gen_loader.c` only copied the loaded `btf_fd` from the
stack to the attributes blob if `btf_value_type_id` was non-zero.
Because `STRUCT_OPS` maps explicitly zero out `btf_value_type_id`, the
loader program skipped copying `btf_fd`, leaving it as `0` (standard
input), which caused the kernel's `btf_get_by_fd(0)` check to fail.

Fix this by:

1. Copying `btf_vmlinux_value_type_id` from the options inside
   `bpf_gen__map_create()`.
2. Modifying the `btf_fd` copying condition to populate `btf_fd` if
   either `btf_value_type_id` OR `btf_vmlinux_value_type_id` is set.

Signed-off-by: Siddharth Nayyar <sidnayyar@google.com>
---
 tools/lib/bpf/gen_loader.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/tools/lib/bpf/gen_loader.c b/tools/lib/bpf/gen_loader.c
index cd5c2543f54d..a9be0c241025 100644
--- a/tools/lib/bpf/gen_loader.c
+++ b/tools/lib/bpf/gen_loader.c
@@ -525,13 +525,14 @@ void bpf_gen__map_create(struct bpf_gen *gen,
 	attr.max_entries = tgt_endian(max_entries);
 	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);
+	attr.btf_vmlinux_value_type_id = tgt_endian(map_attr->btf_vmlinux_value_type_id);
 
 	map_create_attr = add_data(gen, &attr, attr_size);
 	pr_debug("gen: map_create: %s idx %d type %d value_type_id %d, attr: off %d size %d\n",
 		 map_name, map_idx, map_type, map_attr->btf_value_type_id,
 		 map_create_attr, attr_size);
 
-	if (map_attr->btf_value_type_id)
+	if (map_attr->btf_value_type_id || map_attr->btf_vmlinux_value_type_id)
 		/* populate union bpf_attr with btf_fd saved in the stack earlier */
 		move_stack2blob(gen, attr_field(map_create_attr, btf_fd), 4,
 				stack_off(btf_fd));

-- 
2.54.0.746.g67dd491aae-goog

Re: [PATCH v3 0/3] libbpf: support STRUCT_OPS in light skeletons

[Alexei Starovoitov]

On Tue, May 26, 2026 at 7:15 AM Siddharth Nayyar <sidnayyar@google.com> wrote:
>
>
> With these changes, it is now possible to generate and use light
> skeletons for BPF programs utilizing `STRUCT_OPS`, such as custom
> sched_ext schedulers.

The selftest is mandatory to prove that.

pw-bot: cr

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

[bot+bpf-ci]

[-- Attachment #1: Type: text/plain, Size: 1479 bytes --]

> commit df12a01912b915400d5eedf67067cd516e5d81eb
> Author: Siddharth Nayyar <sidnayyar@google.com>
>
>     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@google.com>

This looks like a bug fix for STRUCT_OPS map creation support. The bug
was introduced in commit f1eeafaa2798 which added the STRUCT_OPS case in
bpf_object__create_map() that only zeroed out btf_value_type_id but
forgot to also zero out btf_key_type_id. This causes kernel validation
to fail for STRUCT_OPS maps.

Should this include:

  Fixes: f1eeafaa2798 ("adding ci files")


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

Re: [PATCH v3 1/3] libbpf: load vmlinux BTF in gen_loader mode for struct_ops

[bot+bpf-ci]

[-- Attachment #1: Type: text/plain, Size: 2634 bytes --]

> libbpf: load vmlinux BTF in gen_loader mode for struct_ops
>
> During light skeleton generation (`bpftool gen skeleton -L`), libbpf
> runs in gen_loader mode. Previously, `bpf_object__load_vmlinux_btf()`
> completely bypassed loading the kernel vmlinux BTF (`obj->btf_vmlinux`)
> if `gen_loader` was active.
>
> However, BPF `struct_ops` maps (such as `sched_ext_ops` maps) require
> resolving the kernel-side struct type IDs and member sizes at
> compile/skeleton generation time. Without loading `btf_vmlinux`, libbpf
> cannot query the kernel BTF types, causing light skeleton generation for
> `struct_ops` to fail or omit crucial type information.
>
> Fix this by modifying the check to load `btf_vmlinux` even in
> `gen_loader` mode if the BPF object actually requires kernel vmlinux BTF
> (e.g. contains `struct_ops` maps).
>
> Signed-off-by: Siddharth Nayyar <sidnayyar@google.com>

This looks like a bug fix for commit 67234743736a which introduced the
gen_loader functionality. Should this include:

  Fixes: 67234743736a ("libbpf: Generate loader program out of BPF ELF file.")

> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> index ab2071fdd3e8..6163e53a2056 100644
> --- a/tools/lib/bpf/libbpf.c
> +++ b/tools/lib/bpf/libbpf.c
> @@ -3590,7 +3590,10 @@ static int bpf_object__load_vmlinux_btf(struct bpf_object *obj, bool force)
> 	int err;
>
> 	/* btf_vmlinux could be loaded earlier */
> -	if (obj->btf_vmlinux || obj->gen_loader)
> +	if (obj->btf_vmlinux)
> +		return 0;
> +
> +	if (obj->gen_loader && !obj_needs_vmlinux_btf(obj))
> 		return 0;
>
> 	if (!force && !obj_needs_vmlinux_btf(obj))

Does this change provide a complete solution for struct_ops support in
light skeleton mode? In the earlier review thread, Alexei Starovoitov
commented:

"That's a step, but please provide an end-to-end solution where
struct-ops and sched-ext programs are supported in lksel mode. This
step alone may be more confusing to users than helpful."

The author responded by expanding this to a 3-patch series in v2/v3.
However, only this first patch is present here. The other patches in
that series were:

- Patch 2/3: Zeroing btf_key_type_id
- Patch 3/3: Plumbing btf_vmlinux_value_type_id in gen_loader

Without those additional changes, will struct_ops maps actually work in
light skeleton generation, or does this incomplete series leave the
feature partially broken?


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

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

[bot+bpf-ci]

[-- Attachment #1: Type: text/plain, Size: 1743 bytes --]

> diff --git a/tools/lib/bpf/gen_loader.c b/tools/lib/bpf/gen_loader.c
> index 9478b8f78f26..b0d8551272f2 100644
> --- a/tools/lib/bpf/gen_loader.c
> +++ b/tools/lib/bpf/gen_loader.c
> @@ -525,13 +525,14 @@ void bpf_gen__map_create(struct bpf_gen *gen,
>  	attr.max_entries = tgt_endian(max_entries);
>  	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);
> +	attr.btf_vmlinux_value_type_id = tgt_endian(map_attr->btf_vmlinux_value_type_id);
>
>  	map_create_attr = add_data(gen, &attr, attr_size);
>  	pr_debug("gen: map_create: %s idx %d type %d value_type_id %d, attr: off %d size %d\n",
>  		 map_name, map_idx, map_type, map_attr->btf_value_type_id,
>  		 map_create_attr, attr_size);
>
> -	if (map_attr->btf_value_type_id)
> +	if (map_attr->btf_value_type_id || map_attr->btf_vmlinux_value_type_id)
>  		/* populate union bpf_attr with btf_fd saved in the stack earlier */
>  		move_stack2blob(gen, attr_field(map_create_attr, btf_fd), 4,
>  				stack_off(btf_fd));

This looks like a bug fix for STRUCT_OPS map creation in gen_loader.
The bug was introduced in commit 992c4225419a ("libbpf: Unify low-level
map creation APIs w/ new bpf_map_create()"), which added
btf_vmlinux_value_type_id support to bpf_map_create() but failed to
plumb it through in gen_loader.c's bpf_gen__map_create() function.

Should this include:

  Fixes: 992c4225419a ("libbpf: Unify low-level map creation APIs w/ new bpf_map_create()")


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