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

[Alan Maguire <alan.maguire@oracle.com>]

On 22/12/2025 19:03, Alexei Starovoitov wrote:
> On Sun, Dec 21, 2025 at 10:58 PM Alan Maguire <alan.maguire@oracle.com> wrote:
>>
>>>
>>> Hold on. I'm missing how libbpf will sanitize things for older kernels?
>>
>> The sanitization we can get from layout info is for handling a kernel built with
>> newer kernel/module BTF. The userspace tooling (libbpf and others) does not fully
>> understand it due to the presence of new kinds. In such a case layout data gives us
>> info to parse it by providing info on kind layout, and libbpf can sanitize it
>> to be usable for some cases (where the type graph is not fatally compromised
>> by the lack of a kind). This will always be somewhat limited, but it
>> does provide more usability than we have today.
> 
> I'm even more confused now. libbpf will sanitize BTF for the sake of
> user space? That's not something it ever did. libbpf sanitizes BTF
> only to

Right; it's an extension of the sanitization concept from what it does today.
Today we sanitize newer _program_ BTF to ensure it is acceptable to a kernel which 
lacks specific aspects of that BTF; the goal here is to support some simple sanitization
of the newer _kernel_ BTF by libbpf to help tools (that know about kind layout but may lack
latest kind info kernel has) to make that kernel BTF usable. Both address mismatches between 
kernel BTF version and userspace. The sanitization available in this case is quite limited,
but it would work for cases like BTF location info where it's optional and doesn't get
entangled in the type graph. We could call it something else if it would help distinguish
the concepts, but it is a similar sort of activity.


> be loaded in the older kernel where the original BTF was
> generated for a newer one. There is no reason to mangle BTF right until
> the point of loading. Presence of a kind layout helps user space tooling
> to print it, but that's not sanitization. The tools will just skip over.

With the help of flags, we can do a bit more than just have bpftool print types; we can
also support generation of a vmlinux.h in some cases, support some fentry tracing etc.
Anything that requires a close type match or relies on the newer BTF features we do not
support will not work of course, but it still salvages some usability when kernel BTF is
newer.