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

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..

> 
> ---
> 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/22482435858
> 
> AI-authorship-score: low
> AI-authorship-explanation: Standard UAPI structure definition from a known kernel developer with prior lore discussion links and Suggested-by tag, consistent with human authorship.
> issues-found: 1
> issue-severity-score: medium
> issue-severity-explanation: UAPI header change increases sizeof(struct btf_header), breaking libbpf cross-endian BTF loading for all pre-existing non-native-endian BTF data; fixed in the next patch in the series.