From: sashiko-bot@kernel.org
To: "Jiri Olsa" <jolsa@kernel.org>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCHv5 09/13] selftests/bpf: Change uprobe syscall tests to use nop10
Date: Wed, 01 Jul 2026 11:33:52 +0000 [thread overview]
Message-ID: <20260701113352.8D1141F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260701111337.53943-10-jolsa@kernel.org>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] The patch updates test expectations to look for an 11-byte NOP sequence but fails to update the default `USDT_NOP` in `usdt.h`, causing a guaranteed test failure.
- [Medium] `check_detach()` only verifies the first 5 bytes of the restored 10-byte NOP instruction, potentially masking an instruction stream corruption bug in the kernel.
--
commit 6e149e271696edf6debf9408dedc04512556082d
Author: Jiri Olsa <jolsa@kernel.org>
Subject: selftests/bpf: Change uprobe syscall tests to use nop10
This patch updates the uprobe syscall tests to reflect that optimized uprobes
now operate on top of 10-byte nop instructions.
> diff --git a/tools/testing/selftests/bpf/prog_tests/uprobe_syscall.c b/tools/testing/selftests/bpf/prog_tests/uprobe_syscall.c
> index 955a37751b52d..0bb37435ce97b 100644
> --- a/tools/testing/selftests/bpf/prog_tests/uprobe_syscall.c
> +++ b/tools/testing/selftests/bpf/prog_tests/uprobe_syscall.c
[ ... ]
> @@ -430,9 +432,11 @@ static void *check_attach(struct uprobe_syscall_executed *skel, trigger_t trigge
>
> static void check_detach(void *addr, void *tramp)
> {
> + static const unsigned char nop10_prefix[] = { 0x66, 0x2e, 0x0f, 0x1f, 0x84 };
> +
> /* [uprobes_trampoline] stays after detach */
> ASSERT_OK(find_uprobes_trampoline(tramp), "uprobes_trampoline");
> - ASSERT_OK(memcmp(addr, nop5, 5), "nop5");
> + ASSERT_OK(memcmp(addr, nop10_prefix, 5), "nop10_prefix");
[Severity: Medium]
Does checking only the first 5 bytes mask potential kernel-side unpatching bugs?
The optimized uprobe logic patches a 10-byte sequence, but check_detach() only
verifies the first 5 bytes of the restored instruction. If the kernel's
unpatching logic fails to restore the remaining 5 bytes, they will still
contain part of the call instruction, leaving the execution stream corrupted.
Could we verify the full 10 bytes to ensure the instruction is correctly
and completely restored?
> diff --git a/tools/testing/selftests/bpf/prog_tests/usdt.c b/tools/testing/selftests/bpf/prog_tests/usdt.c
> index 69759b27794d7..fda3a298ccfc7 100644
> --- a/tools/testing/selftests/bpf/prog_tests/usdt.c
> +++ b/tools/testing/selftests/bpf/prog_tests/usdt.c
[ ... ]
> @@ -271,17 +271,17 @@ static void subtest_optimized_attach(void)
> __u8 *addr_1, *addr_2;
>
> /* usdt_1 USDT probe has single nop instruction */
> - addr_1 = find_instr(usdt_1, nop1_nop5_combo, 6);
> - if (!ASSERT_NULL(addr_1, "usdt_1_find_nop1_nop5_combo"))
> + addr_1 = find_instr(usdt_1, nop1_nop10_combo, 11);
> + if (!ASSERT_NULL(addr_1, "usdt_1_find_nop1_nop10_combo"))
> return;
>
> addr_1 = find_instr(usdt_1, nop1, 1);
> if (!ASSERT_OK_PTR(addr_1, "usdt_1_find_nop1"))
> return;
>
> - /* usdt_2 USDT probe has nop,nop5 instructions combo */
> - addr_2 = find_instr(usdt_2, nop1_nop5_combo, 6);
> - if (!ASSERT_OK_PTR(addr_2, "usdt_2_find_nop1_nop5_combo"))
> + /* usdt_2 USDT probe has nop,nop10 instructions combo */
> + addr_2 = find_instr(usdt_2, nop1_nop10_combo, 11);
> + if (!ASSERT_OK_PTR(addr_2, "usdt_2_find_nop1_nop10_combo"))
[Severity: Medium]
Will this test fail because usdt.h wasn't updated?
It appears the default USDT_NOP in tools/testing/selftests/bpf/usdt.h for
x86_64 is still defined as a 6-byte instruction:
#elif defined(__x86_64__)
#define USDT_NOP .byte 0x90, 0x0f, 0x1f, 0x44, 0x00, 0x0 /* nop, nop5 */
Since usdt_2.c relies on this default macro, won't it still compile with the old
6-byte sequence, causing this find_instr() check for 11 bytes to return NULL?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260701111337.53943-10-jolsa@kernel.org?part=1
next prev parent reply other threads:[~2026-07-01 11:33 UTC|newest]
Thread overview: 29+ 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-03 9:55 ` [tip: perf/urgent] " tip-bot2 for Jiri Olsa
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
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 [this message]
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
2026-07-03 10:58 ` Peter Zijlstra
2026-07-03 11:07 ` 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=20260701113352.8D1141F000E9@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.