Re: [PATCH bpf-next 3/6] libbpf: Add feature for kernel extended vlen/kind support

Alexei Starovoitov
2026-04-16T14:15:41Z

On Thu Apr 16, 2026 at 1:57 AM PDT, Alan Maguire wrote:
> On 15/04/2026 16:57, Mykyta Yatsenko wrote:
>>
>>
>> On 4/14/26 8:50 PM, Alan Maguire wrote:
>>> Add feature check for kernel extended vlen/kind support, and reject
>>> BTF that uses extended vlens/kinds if the kernel does not support
>>> it.  There is no reasonable path to generally sanitize such BTF.
>>>
>>> Signed-off-by: Alan Maguire <alan.maguire@oracle.com>
>>> ---
>>>   tools/lib/bpf/features.c        | 39 +++++++++++++++++++++++++++++++++
>>>   tools/lib/bpf/libbpf.c          | 17 +++++++++++++-
>>>   tools/lib/bpf/libbpf_internal.h |  2 ++
>>>   3 files changed, 57 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/tools/lib/bpf/features.c b/tools/lib/bpf/features.c
>>> index 4f19a0d79b0c..4a75d6717bbb 100644
>>> --- a/tools/lib/bpf/features.c
>>> +++ b/tools/lib/bpf/features.c
>>> @@ -615,6 +615,42 @@ static int probe_kern_btf_layout(int token_fd)
>>>                            (char *)layout, token_fd));
>>>   }
>>>   +static int probe_kern_btf_vlen_kind_extended(int token_fd)
>>> +{
>>> +    struct btf *btf;
>>> +    int ret = 0;
>>> +    __s32 id;
>>> +    int err;
>>> +
>>> +    btf = btf__load_vmlinux_btf();
>>> +    err = libbpf_get_error(btf);
>>> +    if (err)
>>> +        return err;
>>> +    id = btf__find_by_name_kind(btf, "btf_max", BTF_KIND_ENUM);
>>
>> Looks like if id > 0 then extended vlen and kinds are available, so there is no point to continue processing the enum and checking value of the BTF_MAX_VLEN. Or is there a scenario, where BTF_MAX_VLEN goes back to 0xffff?
>>
>
> True, the enum presence is enough here. However another point the
> bots made here needs to be addressed; other BTF kernel probes rely
> on the bpf syscall, loading BTF into the kernel to check for feature
> support. We're better off using that approach here too since it will
> work even in container envs which don't have /sys/kernel/btf availability.

If containers cannot access vmlinux BTF than they will fail loading
all progs that need CO-RE. So I don't think we really need syscall
based feature detection. If it's easy enough, sure, we can have it too.
But enum is enough. The verifier exposes its features via BPF_FEAT* enum only.
See enum bpf_features.