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

bot+bpf-ci
2025-12-10T20:55:39Z

[-- Attachment #1: Type: text/plain, Size: 2541 bytes --]

> diff --git a/include/uapi/linux/btf.h b/include/uapi/linux/btf.h
> index 266d4ffa6c07..64dd681274f4 100644
> --- a/include/uapi/linux/btf.h
> +++ b/include/uapi/linux/btf.h
> @@ -8,6 +8,14 @@
> #define BTF_MAGIC 0xeB9F
> #define BTF_VERSION 1
>
> +/* kind layout section consists of a struct btf_kind_layout for each known
> + * kind at BTF encoding time.
> + */
> +struct btf_kind_layout {
> + __u8 info_sz; /* size of singular element after btf_type */
> + __u8 elem_sz; /* size of each of btf_vlen(t) elements */
> +};
> +
> struct btf_header {
> __u16 magic;
> __u8 version;
> @@ -19,6 +27,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 kind_layout_off;/* offset of kind layout section */
> + __u32 kind_layout_len;/* length of kind layout section */
^^^^

Adding these fields to struct btf_header expands it from 24 to 32 bytes.
This breaks compatibility in two ways without implementation support:

1. In kernel/bpf/btf.c, the btf_sec_info_offset[] array at
btf_check_sec_info() only includes type_off and str_off, missing the
new kind_layout_off. When btf_check_sec_info() validates sections, it
checks that expected_total == total. If a BTF file contains a
kind_layout section, the validation will fail with "Unsupported
section found" and reject the BTF with -EINVAL.

Can the kernel accept BTF files with kind_layout sections without
updating btf_sec_info_offset[] to include the new field?

Note: This is fixed in commit e82981d01e84 which adds kind_layout_off
to the validation array.

2. In tools/lib/bpf/btf.c at btf_sanity_check(), when handling
non-native endianness, there's an exact equality check:

if (bswap_32(hdr->hdr_len) != sizeof(struct btf_header))

With sizeof(struct btf_header) now 32 bytes, this check will reject
old BTF files with 24-byte headers. Does this break loading of
existing BTF files that have non-native endianness?

Note: This is fixed in commit a018196d8c9e which changes the check to
a minimum size comparison instead of exact equality.

> diff --git a/tools/include/uapi/linux/btf.h b/tools/include/uapi/linux/btf.h

[ ... ]

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