Re: [PATCH v4 0/3] libbpf: support STRUCT_OPS in light skeletons
From: Sid Nayyar
Date: Fri May 29 2026 - 06:36:30 EST
On Thu, May 28, 2026 at 10:35 PM Andrii Nakryiko
<andrii.nakryiko@xxxxxxxxx> wrote:
>
> On Wed, May 27, 2026 at 5:53 AM Siddharth Nayyar <sidnayyar@xxxxxxxxxx> 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