BPF List
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Jiri Olsa" <jolsa@kernel.org>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCHv5 07/13] libbpf: Detect uprobe syscall with new error
Date: Wed, 01 Jul 2026 11:30:45 +0000	[thread overview]
Message-ID: <20260701113046.4FAE71F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260701111337.53943-8-jolsa@kernel.org>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Unmerged cross-tree dependency breaks `test_uprobe_error()` selftest and drops backward compatibility.
--

commit 7f7a698fa2699de0d1d3b920e07eb13831d5223e
Author: Jiri Olsa <jolsa@kernel.org>

libbpf: Detect uprobe syscall with new error

This commit updates the uprobe syscall feature detection in libbpf and the
corresponding selftest to expect EPROTO instead of ENXIO.

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

[Severity: Medium]
Does modifying this check to strictly require EPROTO break backward
compatibility for libbpf? Older kernels that support the uprobe syscall but
return ENXIO will no longer be detected, which might needlessly prevent the
use of optimized uprobes on those versions.

Could this check accept both ENXIO and EPROTO?

> 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");

[Severity: Medium]
Will this test fail against the current kernel tree? If the kernel patch
changing the return value from ENXIO to EPROTO hasn't been merged yet,
the syscall might still return -ENXIO, causing this assertion to fail when
running the BPF selftests.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260701111337.53943-8-jolsa@kernel.org?part=1

  reply	other threads:[~2026-07-01 11:30 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-01 11:13 [PATCHv5 00/13] uprobes/x86: Fix red zone issue for optimized uprobes Jiri Olsa
2026-07-01 11:13 ` [PATCHv5 01/13] uprobes/x86: Use proper mm_struct in __in_uprobe_trampoline Jiri Olsa
2026-07-01 11:32   ` sashiko-bot
2026-07-01 11:13 ` [PATCHv5 02/13] uprobes/x86: Remove struct uprobe_trampoline object Jiri Olsa
2026-07-01 11:57   ` bot+bpf-ci
2026-07-01 11:13 ` [PATCHv5 03/13] uprobes/x86: Do not leak trampoline vma mapping on optimization failure Jiri Olsa
2026-07-01 11:13 ` [PATCHv5 04/13] uprobes/x86: Allow to copy uprobe trampolines on fork Jiri Olsa
2026-07-01 11:13 ` [PATCHv5 05/13] uprobes/x86: Move optimized uprobe from nop5 to nop10 Jiri Olsa
2026-07-01 11:57   ` bot+bpf-ci
2026-07-01 11:13 ` [PATCHv5 06/13] libbpf: Change has_nop_combo to work on top of nop10 Jiri Olsa
2026-07-01 11:34   ` sashiko-bot
2026-07-01 11:13 ` [PATCHv5 07/13] libbpf: Detect uprobe syscall with new error Jiri Olsa
2026-07-01 11:30   ` sashiko-bot [this message]
2026-07-01 11:13 ` [PATCHv5 08/13] selftests/bpf: Emit nop,nop10 instructions combo for x86_64 arch Jiri Olsa
2026-07-01 11:26   ` sashiko-bot
2026-07-01 11:13 ` [PATCHv5 09/13] selftests/bpf: Change uprobe syscall tests to use nop10 Jiri Olsa
2026-07-01 11:33   ` sashiko-bot
2026-07-01 11:13 ` [PATCHv5 10/13] selftests/bpf: Change uprobe/usdt trigger bench code " Jiri Olsa
2026-07-01 11:13 ` [PATCHv5 11/13] selftests/bpf: Add reattach tests for uprobe syscall Jiri Olsa
2026-07-01 11:13 ` [PATCHv5 12/13] selftests/bpf: Add tests for uprobe nop10 red zone clobbering Jiri Olsa
2026-07-01 11:57   ` bot+bpf-ci
2026-07-01 11:13 ` [PATCHv5 13/13] selftests/bpf: Add tests for forked/cloned optimized uprobes Jiri Olsa
2026-07-01 11:57   ` bot+bpf-ci
2026-07-01 23:13 ` [PATCHv5 00/13] uprobes/x86: Fix red zone issue for " Andrii Nakryiko
2026-07-02 11:20   ` Jiri Olsa
2026-07-02 16:20     ` Andrii Nakryiko

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=20260701113046.4FAE71F000E9@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox