From: Jiri Olsa <olsajiri@gmail.com>
To: Oleg Nesterov <oleg@redhat.com>
Cc: Jiri Olsa <olsajiri@gmail.com>,
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 18:37:45 +0200 [thread overview]
Message-ID: <Z_aiWdks8SA3mtX6@krava> (raw)
In-Reply-To: <20250409131115.GD32748@redhat.com>
On Wed, Apr 09, 2025 at 03:11:16PM +0200, Oleg Nesterov wrote:
> On 04/09, Jiri Olsa wrote:
> >
> > On Wed, Apr 09, 2025 at 01:28:39PM +0200, Oleg Nesterov wrote:
> > > On 04/08, Jiri Olsa wrote:
> > > >
> > > > --- a/arch/x86/kernel/uprobes.c
> > > > +++ b/arch/x86/kernel/uprobes.c
> > > > @@ -608,6 +608,16 @@ static void riprel_post_xol(struct arch_uprobe *auprobe, struct pt_regs *regs)
> > > > *sr = utask->autask.saved_scratch_register;
> > > > }
> > > > }
> > > > +
> > > > +static int is_nop5_insn(uprobe_opcode_t *insn)
> > > > +{
> > > > + return !memcmp(insn, x86_nops[5], 5);
> > > > +}
> > > > +
> > > > +static bool emulate_nop5_insn(struct arch_uprobe *auprobe)
> > > > +{
> > > > + return is_nop5_insn((uprobe_opcode_t *) &auprobe->insn);
> > > > +}
> > >
> > > Why do we need 2 functions? Can't branch_setup_xol_ops() just use
> > > is_nop5_insn(insn->kaddr) ?
> >
> > I need is_nop5_insn in other changes I have in queue, so did not want
> > to introduce extra changes
>
> But I didn't suggest to remove is_nop5_insn(), I meant that
> branch_setup_xol_ops() can do
>
> if (is_nop5_insn(insn->kaddr))
> goto setup;
> or
> if (is_nop5_insn(auprobe->insn))
> goto setup;
>
> this even looks more readable to me. but I won't insist.
>
> > > For the moment, lets forget about compat tasks on a 64-bit kernel, can't
> > > we simply do something like below?
> >
> > I sent similar change (CONFIG_X86_64 only) in this thread:
> > https://lore.kernel.org/bpf/Z_O0Z1ON1YlRqyny@krava/T/#m59c430fb5a30cb9faeb9587fd672ea0adbf3ef4f
> >
> > uprobe won't attach on nop9/10/11 atm,
>
> Ah, OK, I didn't know. But this means that nop9/10/11 will be rejected
> by uprobe_init_insn() -> is_prefix_bad() before branch_setup_xol_ops() is
> called, right? So I guess it is safe to use ASM_NOP_MAX. Nevermind.
>
> > also I don't have practical justification
> > for doing that.. nop5 seems to have future, because of the optimization
>
> OK, I won't insist, up to you.
>
> 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
I checked and compact process executes 64bit nops just fine,
so we should be ok there
>
> And given that emulate_nop5_insn() compares the whole insn with
> x86_nops[5], I guess we don't even need to check OPCODE1(insn)...
right
> Nevermind.
>
> So, once again, I won't argue.
I'm happy to go with your version, wdyt?
thanks,
jirka
---
diff --git a/arch/x86/kernel/uprobes.c b/arch/x86/kernel/uprobes.c
index 9194695662b2..63ecc5f6c235 100644
--- 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;
+ }
+
switch (opc1) {
case 0xeb: /* jmp 8 */
case 0xe9: /* jmp 32 */
break;
- case 0x90: /* prefix* + nop; same as jmp with .offs = 0 */
- goto setup;
case 0xe8: /* call relative */
branch_clear_offset(auprobe, insn);
next prev parent reply other threads:[~2025-04-09 16:37 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 [this message]
2025-04-09 17:58 ` Oleg Nesterov
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=Z_aiWdks8SA3mtX6@krava \
--to=olsajiri@gmail.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=oleg@redhat.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.