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

Siddharth Nayyar posted 3 patches 1 week, 5 days ago
tools/lib/bpf/gen_loader.c |  3 ++-
tools/lib/bpf/libbpf.c     | 25 +++++++++++++++----------
2 files changed, 17 insertions(+), 11 deletions(-)
[PATCH v4 0/3] libbpf: support STRUCT_OPS in light skeletons
Posted by Siddharth Nayyar 1 week, 5 days ago
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 v4:
- Load btf_vmlinux in gen_loader mode only when BPF object contains
  STRUCT_OPS map.
- Link to v3:
  https://lore.kernel.org/r/20260526-libbpf-load-vmlinux-btf-in-gen_loader-mode-v3-0-5b4fa2a5e1a4@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     | 25 +++++++++++++++----------
 2 files changed, 17 insertions(+), 11 deletions(-)
---
base-commit: c6e99c10fd9855082568cbd71bb2cc5dc90eda53
change-id: 20260522-libbpf-load-vmlinux-btf-in-gen_loader-mode-4474834aa467

Best regards,
-- 
Siddharth Nayyar <sidnayyar@google.com>
Re: [PATCH v4 0/3] libbpf: support STRUCT_OPS in light skeletons
Posted by Andrii Nakryiko 1 week, 3 days ago
On Wed, May 27, 2026 at 5:53 AM Siddharth Nayyar <sidnayyar@google.com> wrote:
>
> 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`.

this type ID search has to happen on target kernel at runtime,
otherwise your lskel will be bound to work only on exact kernel you
used to run bpftool to generate lskel

> - 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 v4:
> - Load btf_vmlinux in gen_loader mode only when BPF object contains
>   STRUCT_OPS map.
> - Link to v3:
>   https://lore.kernel.org/r/20260526-libbpf-load-vmlinux-btf-in-gen_loader-mode-v3-0-5b4fa2a5e1a4@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     | 25 +++++++++++++++----------
>  2 files changed, 17 insertions(+), 11 deletions(-)
> ---
> base-commit: c6e99c10fd9855082568cbd71bb2cc5dc90eda53
> change-id: 20260522-libbpf-load-vmlinux-btf-in-gen_loader-mode-4474834aa467
>
> Best regards,
> --
> Siddharth Nayyar <sidnayyar@google.com>
>
Re: [PATCH v4 0/3] libbpf: support STRUCT_OPS in light skeletons
Posted by Sid Nayyar 1 week, 3 days ago
On Thu, May 28, 2026 at 10:35 PM Andrii Nakryiko
<andrii.nakryiko@gmail.com> wrote:
>
> On Wed, May 27, 2026 at 5:53 AM Siddharth Nayyar <sidnayyar@google.com> wrote:
> >
> > 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`.
>
> this type ID search has to happen on target kernel at runtime,
> otherwise your lskel will be bound to work only on exact kernel you
> used to run bpftool to generate lskel

Thank you for pointing this out. I realized the flaw in my approach
shortly after sending these patches. You're absolutely right,
performing the type ID search at generation time would incorrectly
bind the light skeleton to the specific kernel used during the bpftool
run.

I am currently working on a more robust solution that handles the
STRUCT_OPS type ID resolution on the target kernel at runtime. I’ll
follow up with a revised series once I have properly addressed this.

Regards,
Siddharth Nayyar