Re: [PATCH v8 bpf-next 03/10] libbpf: use kind layout to compute an unknown kind size

[Eduard Zingerman <eddyz87@gmail.com>]

On Tue, 2025-12-16 at 15:00 -0800, Andrii Nakryiko wrote:
> On Tue, Dec 16, 2025 at 2:35 PM Eduard Zingerman <eddyz87@gmail.com> wrote:
> > 
> > On Tue, 2025-12-16 at 14:23 -0800, Andrii Nakryiko wrote:
> > 
> > [...]
> > 
> > > Ok, so what you are saying is that if there is layout info we should
> > > always use that instead of hard-coded knowledge about kind layout,
> > > right? Ok, I can agree to that, but see note about extensibility
> > > below.
> > > 
> > > But that's a bit different from validating that the recorded layout
> > > of, say, BTF_KIND_STRUCT is what we expect (sizeof(struct btf_type) +
> > > vlen * sizeof(struct btf_member)). Because if we enforce that, then we
> > > still preclude any extensions to those layouts in the future. And if
> > > we do that, what's the point of looking at layout info for kinds we do
> > > know about?
> > 
> > If full flexibility is allowed, then all places where e.g. libbpf
> > iterates params or struct members require an update. That's a big
> > change.
> > 
> > I suggested checking layout sizes for existing types as a half-measure
> > allowing to avoid such changes.
> 
> Shouldn't we just say that layout info will never change for the kind?
> Whatever fixed + vlen size it starts with, that's set in stone.

If we are not going full flexibility road (a lot of work with unclear purpose),
then fixing the layouts for existing types is what we should do.
I suggested adding layout sizes check in BTF validation phase to
enforce a consistent view at the BTF layout.

> > > > Given that BTF rewrites would only be unsound in presence of unknown
> > > > types the whole feature looks questionable to me.
> > > 
> > > What are those "BTF rewrites" you are referring to? I'm getting a bit
> > > lost in this discussion, tbh.
> > 
> > E.g. btf__permute(), as it will not permute all types if some of the
> > are unknown. Or dedup.
> 
> Yes, agreed, I don't think we should allow modifications like that of
> course, who said we should?

No one says, I suggested adding a check in libbpf,
so that btf_ensure_modifiable() can report an error in such cases.

> > 
> > > This feature is designed to allow introducing new (presumably,
> > > optional) kinds and not break older versions of libbpf/bpftool to at
> > > least be able to dump known contents. Does the current implementation
> > > achieve that goal? What other goals do you think this feature should
> > > support?
> > 
> > I don't think anything other than dump is possible to support.
> 
> Ok, then we are on the same page.
> 
> One interesting question is what to do about libbpf's BTF
> sanitization? Should we still try to replace unknown types with
> something that byte-size-wise is compatible? It might not work in all
> cases, depending on the semantics of unknown KIND, but it should work
> in practice if we are careful about adding new kinds "responsibly".
> WDYT?

The question here is to how to compute the size for the unknown.
It is possible to have a flag specifying if btf_type->size is a true
size. But computation is more sophisticated for e.g. arrays.
On the other hand, if member of some structure has unknown kind,
it can be safely deleted, as struct has size field and offsets for all
members. So, sanitization by deleting types of unknown kind is
possible to some extent.