Re: [PATCH v10 bpf-next 01/10] btf: add BTF kind layout encoding to UAPI

On Fri, Feb 27, 2026 at 5:36 AM Alan Maguire <[email protected]> wrote:
>
> On 27/02/2026 10:52, [email protected] wrote:
> >> diff --git a/tools/include/uapi/linux/btf.h b/tools/include/uapi/linux/btf.h
> >> index 266d4ffa6c07..638615ebddc2 100644
> >> --- a/tools/include/uapi/linux/btf.h
> >> +++ b/tools/include/uapi/linux/btf.h
> >
> > [ ... ]
> >
> >> @@ -19,6 +29,8 @@ struct btf_header {
> >>      __u32   type_len;       /* length of type section       */
> >>      __u32   str_off;        /* offset of string section     */
> >>      __u32   str_len;        /* length of string section     */
> >> +    __u32   layout_off;     /* offset of layout section     */
> >> +    __u32   layout_len;     /* length of layout section     */
> >>  };
> >
> > Adding these two fields changes sizeof(struct btf_header) from 24
> > to 32 bytes. In libbpf's btf_parse_hdr(), the non-native endian
> > path has a strict equality check:
> >
> > tools/lib/bpf/btf.c:btf_parse_hdr() {
> >     if (hdr->magic == bswap_16(BTF_MAGIC)) {
> >         btf->swapped_endian = true;
> >         if (bswap_32(hdr->hdr_len) != sizeof(struct btf_header)) {
> >             pr_warn("Can't load BTF with non-native endianness "
> >                     "due to unsupported header length %u\n",
> >                     bswap_32(hdr->hdr_len));
> >             return -ENOTSUP;
> >         }
> >     ...
> > }
> >
> > All existing cross-endian BTF has hdr_len=24. After this UAPI
> > change, sizeof(struct btf_header) becomes 32, so bswap_32(24)
> > != 32 and the check rejects them.
> >
> > Would it make sense to update this check in the same patch as
> > the header change? As-is, recompiling libbpf with the new
> > header breaks loading of any pre-existing non-native-endian
> > BTF data.
> >
> > This appears to be addressed in the next patch in the series,
> > aa01655822a6 ("libbpf: Support layout section handling in BTF"),
> > which relaxes the check to a minimum size comparison.
> >
>
> In order to handle all the fallout of the header size change
> in a 100% bisect-friendly way it would be necessary to squash patches
> 1,2 and 6 in this series into a single patch dealing with the UAPI,
> libbpf and kernel handling of same. I'm open to doing this,
> but am conscious of the fact the larger patch might make it harder to
> review (for a human at least). We used to explicitly separate UAPI from
> other changes for BPF, not sure if that's as much of a concern any more..

Yeah. Ignore the bot. No need to squash things.