> commit 234ebb868e2e11460c8be69f6726ec05ff912183
> Author: Yuan Chen <[email protected]>
> Date: Tue Jun 9 21:11:00 2026 +0800
>
> libbpf: Skip bpf_object__probe_loading() when BPF token is in use
>
> bpf_object__probe_loading() tries to load trivial SOCKET_FILTER and
> TRACEPOINT programs to verify the BPF environment works. When a
> BPF token is in use with restricted program type permissions, these
> probe loads may fail because the token does not allow the specific
> program types, even though BPF loading is perfectly functional.
>
> Fix by skipping the probe when a token FD is present: BPF token
> creation itself proves the kernel has a working BPF subsystem.
> Real BPF issues will be caught during actual program and map loading.
>
> Signed-off-by: Yuan Chen <[email protected]>
This looks like a fix for a regression introduced when token_fd was wired
into feature probing logic. The CI bot suggested in the v2 review that this
should include:
Fixes: f3dcee938f48 ("libbpf: Wire up token_fd into feature probing logic")
The commit f3dcee938f48 added token_fd support to bpf_object__probe_loading(),
which made the trivial SOCKET_FILTER and TRACEPOINT probe loads subject to the
token's restricted program-type permissions. This can cause the probes to fail
even when BPF loading is perfectly functional.
Should this patch include the Fixes tag to help backporting and tracking the
regression it addresses?
> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> index 3a80a018fc7d..a3ce25928120 100644
> --- a/tools/lib/bpf/libbpf.c
> +++ b/tools/lib/bpf/libbpf.c
> @@ -5167,12 +5167,8 @@ bpf_object__probe_loading(struct bpf_object *obj)
> BPF_EXIT_INSN(),
> };
> int ret, insn_cnt = ARRAY_SIZE(insns);
> - LIBBPF_OPTS(bpf_prog_load_opts, opts,
> - .token_fd = obj->token_fd,
> - .prog_flags = obj->token_fd ? BPF_F_TOKEN_FD : 0,
> - );
>
> - if (obj->gen_loader)
> + if (obj->gen_loader || obj->token_fd)
> return 0;
>
> ret = bump_rlimit_memlock();
> @@ -5181,9 +5177,9 @@ bpf_object__probe_loading(struct bpf_object *obj)
> errstr(ret));
>
> /* make sure basic loading works */
> - ret = bpf_prog_load(BPF_PROG_TYPE_SOCKET_FILTER, NULL, "GPL", insns,
> insn_cnt, &opts);
> + ret = bpf_prog_load(BPF_PROG_TYPE_SOCKET_FILTER, NULL, "GPL", insns,
> insn_cnt, NULL);
> if (ret < 0)
> - ret = bpf_prog_load(BPF_PROG_TYPE_TRACEPOINT, NULL, "GPL",
> insns, insn_cnt, &opts);
> + ret = bpf_prog_load(BPF_PROG_TYPE_TRACEPOINT, NULL, "GPL",
> insns, insn_cnt, NULL);
> if (ret < 0) {
> ret = errno;
> pr_warn("Error in %s(): %s. Couldn't load trivial BPF program.
> Make sure your kernel supports BPF (CONFIG_BPF_SYSCALL=y) and/or that
> RLIMIT_MEMLOCK is set to big enough value.\n",
---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/27208871676
