From: Oleg Nesterov <oleg@redhat.com>
To: Jiri Olsa <olsajiri@gmail.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
Andrii Nakryiko <andrii@kernel.org>,
bpf@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-trace-kernel@vger.kernel.org, x86@kernel.org,
Song Liu <songliubraving@fb.com>, Yonghong Song <yhs@fb.com>,
John Fastabend <john.fastabend@gmail.com>,
Hao Luo <haoluo@google.com>, Steven Rostedt <rostedt@goodmis.org>,
Masami Hiramatsu <mhiramat@kernel.org>,
Alan Maguire <alan.maguire@oracle.com>
Subject: Re: [PATCH 1/2] uprobes/x86: Add support to emulate nop5 instruction
Date: Wed, 9 Apr 2025 19:58:19 +0200 [thread overview]
Message-ID: <20250409175818.GE32748@redhat.com> (raw)
In-Reply-To: <Z_aiWdks8SA3mtX6@krava>
On 04/09, Jiri Olsa wrote:
>
> > Just it looks a bit strange to me. Even if we do not have a use-case
> > for other nops, why we can't emulate them all just for consistency?
>
> we can, I went with nop5 just for simplicity, if you think
> having all nops support is better, let's do that
Well... Let me repeat, I am not really arguing and I do not want to delay
your next changes. We can always cleanup this code later. Please see below.
> I checked and compact process executes 64bit nops just fine,
> so we should be ok there
OK. Then, for your original patch:
Acked-by: Oleg Nesterov <oleg@redhat.com>
I'd only ask to define is_nop5_insn/emulate_nop5_insn regardless of
CONFIG_X86_64. I understand that we have no reason to emulate nop5
on the 32-bit kernel, but at the same time I don't see any reason to
complicate this code to explicitly "nack" nop5 in this case.
As for the new version below:
> --- a/arch/x86/kernel/uprobes.c
> +++ b/arch/x86/kernel/uprobes.c
> @@ -840,12 +840,16 @@ static int branch_setup_xol_ops(struct arch_uprobe *auprobe, struct insn *insn)
> insn_byte_t p;
> int i;
>
> + /* x86_nops[i]; same as jmp with .offs = 0 */
> + for (i = 1; i <= ASM_NOP_MAX; ++i) {
> + if (!memcmp(insn->kaddr, x86_nops[i], i))
> + goto setup;
> + }
Well, yes, I'd personally obviously prefer this version ;) Just because
it looks a bit more clear/consistent to me. But this is subjective.
And,
> - case 0x90: /* prefix* + nop; same as jmp with .offs = 0 */
> - goto setup;
No, this is wrong. Please see my reply to myself,
https://lore.kernel.org/all/20250409114950.GB32748@redhat.com/
This way we can no longer emulate, say, "rep; nop". Exactly because
either way memcmp(x86_nops[i]) checks the whole instruction.
Probably we don't really care, but still this patch shouldn't add any
"regression".
So, let me repeat. Up to you. Whatever you prefer. I just tried to
understand your patch.
You have my ACK in any case.
Oleg.
next prev parent reply other threads:[~2025-04-09 17:59 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-08 21:13 [PATCH 1/2] uprobes/x86: Add support to emulate nop5 instruction Jiri Olsa
2025-04-08 21:13 ` [PATCH 2/2] selftests/bpf: Add 5-byte nop uprobe trigger bench Jiri Olsa
2025-04-09 11:43 ` [tip: perf/core] selftests/bpf: Add 5-byte NOP " tip-bot2 for Jiri Olsa
2025-04-09 11:28 ` [PATCH 1/2] uprobes/x86: Add support to emulate nop5 instruction Oleg Nesterov
2025-04-09 11:49 ` Oleg Nesterov
2025-04-09 12:08 ` Jiri Olsa
2025-04-09 13:11 ` Oleg Nesterov
2025-04-09 16:37 ` Jiri Olsa
2025-04-09 17:58 ` Oleg Nesterov [this message]
2025-04-09 11:43 ` [tip: perf/core] uprobes/x86: Add support to emulate NOP5 instruction tip-bot2 for Jiri Olsa
2025-04-09 14:07 ` Peter Zijlstra
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=20250409175818.GE32748@redhat.com \
--to=oleg@redhat.com \
--cc=alan.maguire@oracle.com \
--cc=andrii@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=haoluo@google.com \
--cc=john.fastabend@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=mhiramat@kernel.org \
--cc=olsajiri@gmail.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=songliubraving@fb.com \
--cc=x86@kernel.org \
--cc=yhs@fb.com \
/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.