From: "Alexei Starovoitov" <alexei.starovoitov@gmail.com>
To: "Alan Maguire" <alan.maguire@oracle.com>,
"Mykyta Yatsenko" <mykyta.yatsenko5@gmail.com>, <ast@kernel.org>,
<daniel@iogearbox.net>, <andrii@kernel.org>
Cc: <martin.lau@linux.dev>, <eddyz87@gmail.com>, <memxor@gmail.com>,
<song@kernel.org>, <yonghong.song@linux.dev>, <jolsa@kernel.org>,
<qmo@kernel.org>, <bpf@vger.kernel.org>
Subject: Re: [PATCH bpf-next 3/6] libbpf: Add feature for kernel extended vlen/kind support
Date: Thu, 16 Apr 2026 07:15:38 -0700 [thread overview]
Message-ID: <DHUN58WZBKWO.PDU8NW80LH0M@gmail.com> (raw)
In-Reply-To: <2d08ed60-9180-4804-8339-7d0e56640183@oracle.com>
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.
next prev parent reply other threads:[~2026-04-16 14:15 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-14 19:50 [PATCH bpf-next 0/6] btf: Extend vlen, kind in struct btf_type Alan Maguire
2026-04-14 19:50 ` [PATCH bpf-next 1/6] bpf: Extend BTF UAPI vlen, kinds to use unused bits Alan Maguire
2026-04-14 20:42 ` bot+bpf-ci
2026-04-14 21:11 ` sashiko-bot
2026-04-15 15:48 ` Mykyta Yatsenko
2026-04-14 19:50 ` [PATCH bpf-next 2/6] libbpf: Adjust btf_vlen() to return a __u32 Alan Maguire
2026-04-14 21:39 ` sashiko-bot
2026-04-14 19:50 ` [PATCH bpf-next 3/6] libbpf: Add feature for kernel extended vlen/kind support Alan Maguire
2026-04-14 20:29 ` bot+bpf-ci
2026-04-14 21:58 ` sashiko-bot
2026-04-15 1:56 ` Alexei Starovoitov
2026-04-15 15:57 ` Mykyta Yatsenko
2026-04-16 8:57 ` Alan Maguire
2026-04-16 14:15 ` Alexei Starovoitov [this message]
2026-04-14 19:50 ` [PATCH bpf-next 4/6] bpftool: Support 24-bit vlen Alan Maguire
2026-04-14 22:12 ` sashiko-bot
2026-04-14 19:50 ` [PATCH bpf-next 5/6] selftests/bpf: Test BTF sanitization rejection for invalid vlen Alan Maguire
2026-04-14 22:26 ` sashiko-bot
2026-04-15 16:03 ` Mykyta Yatsenko
2026-04-14 19:50 ` [PATCH bpf-next 6/6] selftests/bpf: Fix up btf/invalid test for extended kind Alan Maguire
2026-04-14 22:32 ` sashiko-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DHUN58WZBKWO.PDU8NW80LH0M@gmail.com \
--to=alexei.starovoitov@gmail.com \
--cc=alan.maguire@oracle.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=jolsa@kernel.org \
--cc=martin.lau@linux.dev \
--cc=memxor@gmail.com \
--cc=mykyta.yatsenko5@gmail.com \
--cc=qmo@kernel.org \
--cc=song@kernel.org \
--cc=yonghong.song@linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox