Re: [PATCH v12 bpf-next 1/8] btf: add BTF kind layout encoding to UAPI

> diff --git a/tools/include/uapi/linux/btf.h b/tools/include/uapi/linux/btf.h
> --- 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,
9aabbd83dae5 ("libbpf: Support layout section handling in BTF"),
which relaxes the check to a minimum size comparison.


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