From: sashiko-bot@kernel.org
To: "Jiri Olsa" <jolsa@kernel.org>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCHv2 05/11] libbpf: Detect uprobe syscall with new error
Date: Mon, 18 May 2026 11:31:26 +0000 [thread overview]
Message-ID: <20260518113126.938ECC2BCB7@smtp.kernel.org> (raw)
In-Reply-To: <20260518105957.123445-6-jolsa@kernel.org>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Missing kernel dependency causes immediate selftest failure and libbpf feature detection breakage.
- [High] libbpf feature detection breaks backward compatibility by not accepting the old ENXIO error code.
--
commit 674b83913f8f61b2f16ba8f8b86e6bf8e84da5a3
Author: Jiri Olsa <jolsa@kernel.org>
libbpf: Detect uprobe syscall with new error
This commit updates libbpf's feature detection and the uprobe selftests to
expect the uprobe syscall to return -EPROTO instead of -ENXIO. This is in
response to an optimized uprobe fix that changed the syscall's error code.
> diff --git a/tools/lib/bpf/features.c b/tools/lib/bpf/features.c
> index 4f19a0d79b0cf..a37aaea5253e5 100644
> --- a/tools/lib/bpf/features.c
> +++ b/tools/lib/bpf/features.c
> @@ -577,10 +577,10 @@ static int probe_ldimm64_full_range_off(int token_fd)
> static int probe_uprobe_syscall(int token_fd)
> {
> /*
> - * If kernel supports uprobe() syscall, it will return -ENXIO when called
> + * If kernel supports uprobe() syscall, it will return -EPROTO when called
> * from the outside of a kernel-generated uprobe trampoline.
> */
> - return syscall(__NR_uprobe) < 0 && errno == ENXIO;
> + return syscall(__NR_uprobe) < 0 && errno == EPROTO;
Is it possible this change breaks libbpf's backward compatibility with older
kernels? Since probe_uprobe_syscall() detects uprobe syscall support on
various kernel versions, replacing the check rather than allowing either
(e.g., errno == ENXIO || errno == EPROTO) might cause libbpf to silently
fail to detect uprobe support on kernels that predate the EPROTO change.
Also, looking at arch/x86/kernel/uprobes.c, the kernel-side change does
not appear to be present in the tree yet:
SYSCALL_DEFINE0(uprobe)
{
...
/* Allow execution only from uprobe trampolines. */
if (!in_uprobe_trampoline(regs->ip))
return -ENXIO;
Will replacing this check cause immediate regressions for both feature
detection and the selftests until the kernel dependency is merged?
[ ... ]
> diff --git a/tools/testing/selftests/bpf/prog_tests/uprobe_syscall.c b/tools/testing/selftests/bpf/prog_tests/uprobe_syscall.c
> index 955a37751b52d..c944136252c6d 100644
> --- a/tools/testing/selftests/bpf/prog_tests/uprobe_syscall.c
> +++ b/tools/testing/selftests/bpf/prog_tests/uprobe_syscall.c
> @@ -762,7 +762,7 @@ static void test_uprobe_error(void)
> long err = syscall(__NR_uprobe);
>
> ASSERT_EQ(err, -1, "error");
> - ASSERT_EQ(errno, ENXIO, "errno");
> + ASSERT_EQ(errno, EPROTO, "errno");
Similarly, does this selftest change introduce an immediate regression if
the running kernel still returns -ENXIO?
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260518105957.123445-6-jolsa@kernel.org?part=1
next prev parent reply other threads:[~2026-05-18 11:31 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-18 10:59 [PATCHv2 00/11] uprobes/x86: Fix red zone issue for optimized uprobes Jiri Olsa
2026-05-18 10:59 ` [PATCHv2 01/11] uprobes/x86: Use proper mm_struct in __in_uprobe_trampoline Jiri Olsa
2026-05-18 10:59 ` [PATCHv2 02/11] uprobes/x86: Allow to copy uprobe trampolines on fork Jiri Olsa
2026-05-18 11:42 ` sashiko-bot
2026-05-18 12:50 ` Jiri Olsa
2026-05-18 16:04 ` Jiri Olsa
2026-05-18 10:59 ` [PATCHv2 03/11] uprobes/x86: Move optimized uprobe from nop5 to nop10 Jiri Olsa
2026-05-18 11:50 ` bot+bpf-ci
2026-05-18 10:59 ` [PATCHv2 04/11] libbpf: Change has_nop_combo to work on top of nop10 Jiri Olsa
2026-05-18 11:37 ` bot+bpf-ci
2026-05-19 20:36 ` Jiri Olsa
2026-05-18 10:59 ` [PATCHv2 05/11] libbpf: Detect uprobe syscall with new error Jiri Olsa
2026-05-18 11:31 ` sashiko-bot [this message]
2026-05-19 20:36 ` Jiri Olsa
2026-05-18 11:37 ` bot+bpf-ci
2026-05-18 17:39 ` Andrii Nakryiko
2026-05-18 10:59 ` [PATCHv2 06/11] selftests/bpf: Emit nop,nop10 instructions combo for x86_64 arch Jiri Olsa
2026-05-18 11:17 ` sashiko-bot
2026-05-19 20:36 ` Jiri Olsa
2026-05-18 10:59 ` [PATCHv2 07/11] selftests/bpf: Change uprobe syscall tests to use nop10 Jiri Olsa
2026-05-18 11:16 ` sashiko-bot
2026-05-19 20:36 ` Jiri Olsa
2026-05-18 11:50 ` bot+bpf-ci
2026-05-18 10:59 ` [PATCHv2 08/11] selftests/bpf: Change uprobe/usdt trigger bench code " Jiri Olsa
2026-05-18 11:37 ` bot+bpf-ci
2026-05-18 10:59 ` [PATCHv2 09/11] selftests/bpf: Add reattach tests for uprobe syscall Jiri Olsa
2026-05-18 10:59 ` [PATCHv2 10/11] selftests/bpf: Add tests for uprobe nop10 red zone clobbering Jiri Olsa
2026-05-18 10:59 ` [PATCHv2 11/11] selftests/bpf: Add tests for forked/cloned optimized uprobes Jiri Olsa
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=20260518113126.938ECC2BCB7@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=jolsa@kernel.org \
--cc=sashiko-reviews@lists.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.