From: Jiri Olsa <olsajiri@gmail.com>
To: bot+bpf-ci@kernel.org
Cc: oleg@redhat.com, peterz@infradead.org, mingo@kernel.org,
mhiramat@kernel.org, andrii@kernel.org, bpf@vger.kernel.org,
linux-trace-kernel@vger.kernel.org, ast@kernel.org,
daniel@iogearbox.net, martin.lau@kernel.org, eddyz87@gmail.com,
yonghong.song@linux.dev, clm@meta.com, ihor.solodrai@linux.dev
Subject: Re: [PATCHv4 09/13] selftests/bpf: Change uprobe syscall tests to use nop10
Date: Wed, 27 May 2026 11:58:19 +0200 [thread overview]
Message-ID: <ahbAOwmPl2KJDPbb@krava> (raw)
In-Reply-To: <3bec8cfe67b2e52b7316d77f6907373a99ee0443a27c15ad26b90d6c5539ecdf@mail.kernel.org>
On Tue, May 26, 2026 at 09:46:38PM +0000, bot+bpf-ci@kernel.org wrote:
SNIP
> > diff --git a/tools/testing/selftests/bpf/prog_tests/usdt.c b/tools/testing/selftests/bpf/prog_tests/usdt.c
> > index 69759b27794d..fda3a298ccfc 100644
> > --- a/tools/testing/selftests/bpf/prog_tests/usdt.c
> > +++ b/tools/testing/selftests/bpf/prog_tests/usdt.c
> > @@ -252,7 +252,7 @@ extern void usdt_1(void);
> > extern void usdt_2(void);
> >
> > static unsigned char nop1[1] = { 0x90 };
> > -static unsigned char nop1_nop5_combo[6] = { 0x90, 0x0f, 0x1f, 0x44, 0x00, 0x00 };
> > +static unsigned char nop1_nop10_combo[11] = { 0x90, 0x66, 0x2e, 0x0f, 0x1f, 0x84, 0x00, 0x00, 0x00, 0x00, 0x00 };
> >
> > static void *find_instr(void *fn, unsigned char *instr, size_t cnt)
> > {
>
> Is the loop in find_instr() adequate to find the updated instruction
> sequence? In uprobe_syscall.c, find_nop10() was updated to search up
> to 128 bytes to account for compiler-generated prologues:
>
> tools/testing/selftests/bpf/prog_tests/uprobe_syscall.c:find_nop10() {
> for (i = 0; i < 128; i++) {
> if (!memcmp(nop10, fn + i, 10))
> return fn + i;
> }
> }
>
> But find_instr() in usdt.c only searches the first 10 bytes:
>
> tools/testing/selftests/bpf/prog_tests/usdt.c:find_instr() {
> for (i = 0; i < 10; i++) {
> if (!memcmp(instr, fn + i, cnt))
> return fn + i;
> }
> }
>
> If a modern compiler generates a prologue longer than 9 bytes for
> usdt_2(), find_instr() will prematurely terminate and cause
> subtest_optimized_attach() to fail. This concern was raised by
> reviewers in v2 and v3 of the patch series:
find_instr is ok for its usage in subtest_optimized_attach,
we first use it to verify the combo was not generated in usdt_1,
and having 128 bytes search we'd find combo from usdt_2 function
modern compilers seems to be smart emough not to generate long
prologue for usdt_2 function
jirka
next prev parent reply other threads:[~2026-05-27 9:58 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
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 [this message]
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=ahbAOwmPl2KJDPbb@krava \
--to=olsajiri@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bot+bpf-ci@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=clm@meta.com \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=ihor.solodrai@linux.dev \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=martin.lau@kernel.org \
--cc=mhiramat@kernel.org \
--cc=mingo@kernel.org \
--cc=oleg@redhat.com \
--cc=peterz@infradead.org \
--cc=yonghong.song@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.