From: sashiko-bot@kernel.org
To: "Jiri Olsa" <jolsa@kernel.org>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCHv4 06/13] libbpf: Change has_nop_combo to work on top of nop10
Date: Tue, 26 May 2026 21:28:39 +0000 [thread overview]
Message-ID: <20260526212840.1053C1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260526205840.173790-7-jolsa@kernel.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The patch invalidly replaces `nop5` optimization support with `nop10`, which cannot be optimized by the kernel, breaks backward compatibility for existing binaries, and causes selftest failures.
--
commit df13b5dc7675e7ea56d8d1775d22295b93e92ab0
Author: Jiri Olsa <jolsa@kernel.org>
libbpf: Change has_nop_combo to work on top of nop10
This commit updates the USDT nop combo detection to expect a 10-byte nop
instead of a 5-byte nop. It updates has_nop_combo() to match the new byte
sequence.
> diff --git a/tools/lib/bpf/usdt.c b/tools/lib/bpf/usdt.c
> index e3710933fd52a..484a4354e82ba 100644
> --- a/tools/lib/bpf/usdt.c
> +++ b/tools/lib/bpf/usdt.c
[ ... ]
> @@ -596,14 +596,14 @@ static int parse_usdt_spec(struct usdt_spec *spec, const struct usdt_note *note,
> #if defined(__x86_64__)
> static bool has_nop_combo(int fd, long off)
> {
> - unsigned char nop_combo[6] = {
> - 0x90, 0x0f, 0x1f, 0x44, 0x00, 0x00 /* nop,nop5 */
> + unsigned char nop_combo[11] = {
> + 0x90, 0x66, 0x2e, 0x0f, 0x1f, 0x84, 0x00, 0x00, 0x00, 0x00, 0x00,
> };
> - unsigned char buf[6];
> + unsigned char buf[11];
>
> - if (pread(fd, buf, 6, off) != 6)
> + if (pread(fd, buf, 11, off) != 11)
> return false;
> - return memcmp(buf, nop_combo, 6) == 0;
> + return memcmp(buf, nop_combo, 11) == 0;
> }
[Severity: High]
Does replacing the 5-byte nop detection with a 10-byte nop detection break the
kernel's uprobe optimization logic?
Looking at the kernel's can_optimize() in arch/x86/kernel/uprobes.c, it
strictly requires the replaced instruction to be exactly 5 bytes. A 10-byte
instruction fails this length check, causing the kernel to silently abort
optimization and fall back to an unoptimized int3 probe.
Additionally, replacing this entirely rather than supplementing it means
libbpf no longer recognizes the nop5 combo in existing binaries. This causes
existing USDTs to fall back to unoptimized probes and breaks BPF selftests
that expect the +1 offset applied.
Finally, if the kernel ever updated can_optimize() to allow 10-byte nops,
sys_uprobe() currently hardcodes a return adjustment of regs->ip += 5.
Returning +5 bytes into a 10-byte instruction would resume execution in the
middle of the nop sequence, which could cause an application crash.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260526205840.173790-7-jolsa@kernel.org?part=1
next prev parent reply other threads:[~2026-05-26 21:28 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-26 20:58 [PATCHv4 00/13] uprobes/x86: Fix red zone issue for optimized uprobes Jiri Olsa
2026-05-26 20:58 ` [PATCHv4 01/13] uprobes/x86: Use proper mm_struct in __in_uprobe_trampoline Jiri Olsa
2026-05-26 20:58 ` [PATCHv4 02/13] uprobes/x86: Remove struct uprobe_trampoline object Jiri Olsa
2026-05-26 21:46 ` bot+bpf-ci
2026-05-27 9:58 ` Jiri Olsa
2026-06-01 8:31 ` Jiri Olsa
2026-05-26 20:58 ` [PATCHv4 03/13] uprobes/x86: Allow to copy uprobe trampolines on fork Jiri Olsa
2026-05-26 21:46 ` bot+bpf-ci
2026-05-27 9:58 ` Jiri Olsa
2026-05-26 20:58 ` [PATCHv4 04/13] uprobes/x86: Unmap trampoline vma object in case it's unused Jiri Olsa
2026-05-26 21:46 ` bot+bpf-ci
2026-05-27 9:57 ` Jiri Olsa
2026-05-26 20:58 ` [PATCHv4 05/13] uprobes/x86: Move optimized uprobe from nop5 to nop10 Jiri Olsa
2026-05-26 20:58 ` [PATCHv4 06/13] libbpf: Change has_nop_combo to work on top of nop10 Jiri Olsa
2026-05-26 21:28 ` sashiko-bot [this message]
2026-05-27 9:57 ` Jiri Olsa
2026-05-26 21:46 ` bot+bpf-ci
2026-05-27 9:57 ` Jiri Olsa
2026-05-26 20:58 ` [PATCHv4 07/13] libbpf: Detect uprobe syscall with new error Jiri Olsa
2026-05-26 21:36 ` sashiko-bot
2026-05-26 21:46 ` bot+bpf-ci
2026-05-26 20:58 ` [PATCHv4 08/13] selftests/bpf: Emit nop,nop10 instructions combo for x86_64 arch Jiri Olsa
2026-05-26 21:19 ` sashiko-bot
2026-05-26 21:46 ` bot+bpf-ci
2026-05-26 20:58 ` [PATCHv4 09/13] selftests/bpf: Change uprobe syscall tests to use nop10 Jiri Olsa
2026-05-26 21:15 ` sashiko-bot
2026-05-27 9:58 ` Jiri Olsa
2026-05-26 21:46 ` bot+bpf-ci
2026-05-27 9:58 ` Jiri Olsa
2026-05-27 10:30 ` Jakub Sitnicki
2026-05-26 20:58 ` [PATCHv4 10/13] selftests/bpf: Change uprobe/usdt trigger bench code " Jiri Olsa
2026-05-27 10:46 ` Jakub Sitnicki
2026-05-26 20:58 ` [PATCHv4 11/13] selftests/bpf: Add reattach tests for uprobe syscall Jiri Olsa
2026-05-27 11:32 ` Jakub Sitnicki
2026-05-28 11:10 ` Jiri Olsa
2026-05-26 20:58 ` [PATCHv4 12/13] selftests/bpf: Add tests for uprobe nop10 red zone clobbering Jiri Olsa
2026-05-26 21:46 ` bot+bpf-ci
2026-05-27 10:26 ` Jiri Olsa
2026-05-28 12:46 ` Jakub Sitnicki
2026-05-26 20:58 ` [PATCHv4 13/13] selftests/bpf: Add tests for forked/cloned optimized uprobes Jiri Olsa
2026-05-28 13:00 ` Jakub Sitnicki
2026-06-01 8:31 ` Jiri Olsa
2026-06-04 6:59 ` [PATCHv4 00/13] uprobes/x86: Fix red zone issue for " 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=20260526212840.1053C1F000E9@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.