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

[sashiko-bot@kernel.org]

Sashiko AI review found 3 potential issue(s):
- [High] The feature probe incorrectly relies on finding an unused enum (`btf_max`) in the `vmlinux` BTF, guaranteeing it will permanently fail and falsely reject valid BPF objects.
- [High] The feature probe violates libbpf's probe architecture by reading the multi-megabyte `vmlinux` BTF instead of using lightweight `bpf()` syscalls, breaking containers and unprivileged token delegation.
- [Medium] The feature probe propagates negative errors when `vmlinux` BTF is absent, unconditionally spamming application logs with multiple warnings.
--

commit 3e8277b7bc260bfb527a032e5667d3e2d753d156
Author: Alan Maguire <alan.maguire@oracle.com>

libbpf: Add feature for kernel extended vlen/kind support
    
This commit adds a new feature probe to detect whether the kernel supports
extended BTF vlen and kind. It does this by loading the vmlinux BTF and
searching for an enum named btf_max with a BTF_MAX_VLEN member greater
than 0xffff.

> diff --git a/tools/lib/bpf/features.c b/tools/lib/bpf/features.c
> index 4f19a0d79b0cf..4a75d6717bbbd 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;

If /sys/kernel/btf/vmlinux does not exist, btf__load_vmlinux_btf() returns
a negative error code. By returning this error directly, won't the
feat_supported() cache layer log a warning message? This seems like it will
spam logs on systems without vmlinux BTF.

Also, since this probe ignores token_fd, does it break BPF token delegation
for unprivileged environments? This approach introduces a dependency on
vmlinux BTF and adds parsing latency, compared to a lightweight bpf() syscall
probe.

> +	id = btf__find_by_name_kind(btf, "btf_max", BTF_KIND_ENUM);
> +	if (id > 0) {
> +		const struct btf_type *t;
> +		const struct btf_enum *e;
> +		const char *name;
> +		__u32 i, vlen;
> +
> +		t = btf__type_by_id(btf, id);
> +		if (t) {
> +			vlen = btf_vlen(t);
> +
> +			for (i = 0, e = btf_enum(t); i < vlen; i++, e++) {
> +				name = btf__name_by_offset(btf, e->name_off);
> +				if (!name || strcmp(name, "BTF_MAX_VLEN") != 0)
> +					continue;
> +				if (e->val > 0xffff)
> +					ret = 1;
> +			}
> +		}
> +	}
> +	btf__free(btf);
> +
> +	return ret;
> +}

Is enum btf_max actually instantiated in kernel C code?

If it is only used as a header construct, won't it be absent from the DWARF
debug info and the vmlinux BTF? If so, this probe would always fail to find
it, causing libbpf to unconditionally reject extended vlen/kind BTFs even on
capable kernels.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260414195019.684531-1-alan.maguire@oracle.com?part=3