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: [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

  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