public inbox for bpf@vger.kernel.org
 help / color / mirror / Atom feed
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.


  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