Re: [PATCH v13 bpf-next 2/8] libbpf: Support layout section handling in BTF

On Wed, Mar 11, 2026 at 12:35 PM Alan Maguire <[email protected]> wrote:
>
> On 11/03/2026 19:21, Andrii Nakryiko wrote:
> > On Wed, Mar 11, 2026 at 12:17 PM Alan Maguire <[email protected]> wrote:
> >>
> >> On 11/03/2026 18:16, Andrii Nakryiko wrote:
> >>> On Wed, Mar 11, 2026 at 11:10 AM Alan Maguire <[email protected]> wrote:
> >>>>
> >>>> On 11/03/2026 17:46, Andrii Nakryiko wrote:
> >>>>> On Fri, Mar 6, 2026 at 3:37 AM Alan Maguire <[email protected]> wrote:
> >>>>>>
> >>>>>> Support reading in layout fixing endian issues on reading;
> >>>>>> also support writing layout section to raw BTF object.
> >>>>>> There is not yet an API to populate the layout with meaningful
> >>>>>> information.
> >>>>>>
> >>>>>> As part of this, we need to consider multiple valid BTF header
> >>>>>> sizes; the original or the layout-extended headers.
> >>>>>> So to support this, the "struct btf" representation is modified
> >>>>>> to contain a "struct btf_header" and we copy the valid
> >>>>>> portion from the raw data to it; this means we can always safely
> >>>>>> check fields like btf->hdr.layout_len
> >>>>>>
> >>>>>> Signed-off-by: Alan Maguire <[email protected]>
> >>>>>> ---
> >>>>>>  tools/lib/bpf/btf.c | 309 ++++++++++++++++++++++++++++----------------
> >>>>>>  1 file changed, 200 insertions(+), 109 deletions(-)
> >>>>>>
> >>>>>
> >>>>> [...]
> >>>>>
> >>>>>>
> >>>>>> -       memcpy(p, hdr, hdr->hdr_len);
> >>>>>> +       memcpy(p, hdr, min((__u32)sizeof(struct btf_header), hdr->hdr_len));
> >>>>>
> >>>>> in all these cases where we have sizeof(struct btf_header), this
> >>>>> smells like a potential issue, tbh. We are silently truncating the
> >>>>> original header here, potentially. Which is ok for read-only case, but
> >>>>> do we error out if someone is trying to modify/write such BTF where we
> >>>>> don't really understand all of it? Should we?
> >>>>>
> >>>>
> >>>> The kernel enforces that any additional data in the header beyond fields
> >>>> we know how to deal with is zero. We don't enforce this here, but we
> >>>> get a similar effect since we only copy the fields we care about. In effect
> >>>> we wind up removing the aspects of the BTF we don't know about, so if we
> >>>> read in such BTF, writing it out would not preserve any additional header
> >>>> information (say a new section offset/length) beyond the current size of
> >>>> struct btf_header. So writing such BTF after reading it in converts it to
> >>>> the BTF representation libbpf knows about (header fields + sections).
> >>>
> >>> I don't think we should be doing this. Let's error out when someone
> >>> tries to modify BTF where we don't understand *all* aspects of it.
> >>>
> >>
> >> ok, so to do this I think we'd need to set a never_modifiable flag or similar
> >> on parsing when we find non-zero unknown header data, and then fail
> >> btf_ensure_modifiable().
> >
> > yep, I'd like some better name that would mean "there are extra btf
> > bits we don't understand", but I can't come up with a better name :)
> > if you can, prefer that over not very semantically meaningful "never
> > modifiable"
> >
>
> would btf->unknown_hdr_data work?

what about btf->has_hdr_extra ?
>