From: sashiko-bot@kernel.org
To: "Jiri Olsa" <jolsa@kernel.org>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCHv2 06/11] selftests/bpf: Emit nop,nop10 instructions combo for x86_64 arch
Date: Mon, 18 May 2026 11:17:33 +0000 [thread overview]
Message-ID: <20260518111733.E696AC2BCB7@smtp.kernel.org> (raw)
In-Reply-To: <20260518105957.123445-7-jolsa@kernel.org>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] The patch modifies `USDT_NOP` to emit an 11-byte `nop, nop10` sequence, breaking existing BPF selftests that explicitly expect `nop, nop5`.
- [Medium] Libbpf is not updated to recognize the new `nop, nop10` sequence, causing the intended uprobe optimization to silently fail.
--
commit 1ccfa6afa421e13f88c377be82ec249ff187bf51
Author: Jiri Olsa <jolsa@kernel.org>
selftests/bpf: Emit nop,nop10 instructions combo for x86_64 arch
This commit updates the USDT_NOP macro in the BPF selftests to use a nop,nop10
instruction sequence instead of nop,nop5 for x86_64. This is intended to
support nop10 optimization testing.
> diff --git a/tools/testing/selftests/bpf/usdt.h b/tools/testing/selftests/bpf/usdt.h
> index c71e21df38b32..d359663b9c329 100644
> --- a/tools/testing/selftests/bpf/usdt.h
> +++ b/tools/testing/selftests/bpf/usdt.h
> @@ -313,7 +313,7 @@ struct usdt_sema { volatile unsigned short active; };
> #if defined(__ia64__) || defined(__s390__) || defined(__s390x__)
> #define USDT_NOP nop 0
> #elif defined(__x86_64__)
> -#define USDT_NOP .byte 0x90, 0x0f, 0x1f, 0x44, 0x00, 0x0 /* nop, nop5 */
> +#define USDT_NOP .byte 0x90, 0x66, 0x66, 0x0f, 0x1f, 0x84, 0x00, 0x00, 0x00, 0x00, 0x00 /* nop, nop10 */
Will this change break the existing BPF selftests that explicitly expect the
nop,nop5 sequence?
Looking at tools/testing/selftests/bpf/prog_tests/usdt.c,
subtest_optimized_attach() uses find_instr() to search for a hardcoded 6-byte
sequence:
const char nop1_nop5_combo[] = { 0x90, 0x0f, 0x1f, 0x44, 0x00, 0x00 };
...
addr_2 = find_instr(usdt_2, nop1_nop5_combo, sizeof(nop1_nop5_combo));
Because usdt_2.c is compiled with the new 11-byte nop,nop10 sequence,
find_instr() will return NULL and cause the ASSERT_OK_PTR() check to fail.
Additionally, does libbpf need to be updated to recognize this new sequence?
In tools/lib/bpf/usdt.c, has_nop_combo() appears to be hardcoded to check only
for the 6-byte nop,nop5 sequence.
If libbpf doesn't recognize the new 11-byte sequence, it won't increment the
instruction pointer to skip the initial 1-byte nop. This would cause the
uprobe to attach to the unoptimized 1-byte nop instead of utilizing the
intended optimization.
> #else
> #define USDT_NOP nop
> #endif
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260518105957.123445-7-jolsa@kernel.org?part=1
next prev parent reply other threads:[~2026-05-18 11:17 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
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 [this message]
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=20260518111733.E696AC2BCB7@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