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 15:11:16 +0200 [thread overview]
Message-ID: <20250409131115.GD32748@redhat.com> (raw)
In-Reply-To: <Z_ZjIerx-QvY7BSI@krava>
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?
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)...
Nevermind.
So, once again, I won't argue.
Oleg.
next prev parent reply other threads:[~2025-04-09 13:12 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 [this message]
2025-04-09 16:37 ` Jiri Olsa
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=20250409131115.GD32748@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.