Re: [PATCH v3 bpf-next 0/6] bpf: Extend BTF UAPI vlen, kinds to use unused bits

Alan Maguire
2026-04-20T19:25:15Z

On 20/04/2026 19:30, David Faust wrote:
>
>
> On 4/17/26 07:30, Alan Maguire wrote:
>> Currently BTF types can have a maximum of 65535 vlen-specified
>> objects. While this limit has not yet been surpassed for existing
>> cases (struct/union fields, enum values, function arguments and
>> datasec), upcoming BTF location information - specifically inline
>> sites - will hit that limit. Utilize unused BTF info bits in
>> struct btf_type to increase limit to 24-bits (over 16 million).
>> This is more than an order of magnitude greater than inline
>> site counts for the kernel (~400,000) so should be enough for
>> the near future at least.
>>
>> Similarly, struct btf_type uses 5 bits for BTF kind values;
>> currently we use 20 kinds, but BTF location information will
>> take another 3, and conceivably providing better support for Rust
>> types in BTF (now that modules can be built using Rust) could
>> push us close to the max of 31. Use 2 unused bits to provide
>> a max possible kind of 127.
>
> Should we bump btf_version in the header for this?
> (e.g. when emitting from compiler)
>
> It may be useful to know that the BTF for a given file was
> constructed with the new limitations like vlen in mind or not.
>

hi David

From a compatibility perspective the kernel has always enforced a requirement
that the unused bits are zero and it will reject BTF which uses those unused bits.
So with this change the kernel will permit extended vlens/kinds but older kernels
will reject such BTF. If the kernel had been more permissive in the past it might
be worth a version bump as it could be argued that it was ambiguous whether the
unused bits had random data in them as opposed to extended vlens.

So in this context I'd say it's not worth a version bump as there's no ambiguity
here; either the formerly unused fields are zeroed to be acceptable to older kernels
or they are used for extended kinds/vlens. Thanks!

Alan