From: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
To: Oleg Nesterov <oleg@redhat.com>
Cc: Ingo Molnar <mingo@elte.hu>,
Ananth N Mavinakayanahalli <ananth@in.ibm.com>,
David Long <dave.long@linaro.org>,
Denys Vlasenko <dvlasenk@redhat.com>,
"Frank Ch. Eigler" <fche@redhat.com>,
Jim Keniston <jkenisto@us.ibm.com>,
Jonathan Lebon <jlebon@redhat.com>,
Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/7] uprobes: Kill UPROBE_SKIP_SSTEP and can_skip_sstep()
Date: Thu, 3 Apr 2014 22:02:19 +0530 [thread overview]
Message-ID: <20140403163219.GA4882@linux.vnet.ibm.com> (raw)
In-Reply-To: <20140331194355.GA9275@redhat.com>
> UPROBE_COPY_INSN, UPROBE_SKIP_SSTEP, and uprobe->flags must die. This
> patch kills UPROBE_SKIP_SSTEP. I never understood why it was added;
> not only it doesn't help, it harms.
>
> It can only help to avoid arch_uprobe_skip_sstep() if it was already
> called before and failed. But this is ugly, if we want to know whether
> we can emulate this instruction or not we should do this analysis in
> arch_uprobe_analyze_insn(), not when we hit this probe for the first
> time.
>
> And in fact this logic is simply wrong. arch_uprobe_skip_sstep() can
> fail or not depending on the task/register state, if this insn can be
> emulated but, say, put_user() fails we need to xol it this time, but
> this doesn't mean we shouldn't try to emulate it when this or another
> thread hist this bp next time.
>
> And this is the actual reason for this change. We need to emulate the
> "call" insn, but push(return-address) can obviously fail.
>
> Per-arch notes:
>
> x86: __skip_sstep() can only emulate "rep;nop". With this
> change it will be called every time and most probably
> for no reason.
>
> This will be fixed by the next changes. We need to
> change this suboptimal code anyway.
>
> arm: Should not be affected. It has its own "bool simulate"
> flag checked in arch_uprobe_skip_sstep().
>
> ppc: Looks like, it can emulate almost everything. Does it
> actually needs to record the fact that emulate_step()
> failed? Hopefully not. But if yes, it can add the ppc-
> specific flag into arch_uprobe.
>
> TODO: rename arch_uprobe_skip_sstep() to arch_uprobe_emulate_insn(),
>
> Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Acked-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
--
Thanks and Regards
Srikar Dronamraju
next prev parent reply other threads:[~2014-04-03 16:32 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-31 19:43 [PATCH 0/7] uprobes/x86: introduce uprobe_xol_ops and arch_uprobe->ops Oleg Nesterov
2014-03-31 19:43 ` [PATCH 1/7] uprobes: Kill UPROBE_SKIP_SSTEP and can_skip_sstep() Oleg Nesterov
2014-04-01 1:41 ` Masami Hiramatsu
2014-04-01 15:39 ` David Long
2014-04-03 16:32 ` Srikar Dronamraju [this message]
2014-03-31 19:43 ` [PATCH 2/7] uprobes/x86: Fold prepare_fixups() into arch_uprobe_analyze_insn() Oleg Nesterov
2014-04-01 2:00 ` Masami Hiramatsu
2014-04-03 16:33 ` Srikar Dronamraju
2014-03-31 19:44 ` [PATCH 3/7] uprobes/x86: Conditionalize the usage of handle_riprel_insn() Oleg Nesterov
2014-04-01 3:17 ` Masami Hiramatsu
2014-04-01 14:33 ` Oleg Nesterov
2014-04-01 16:39 ` Oleg Nesterov
2014-04-02 17:57 ` Jim Keniston
2014-04-02 19:14 ` Oleg Nesterov
2014-03-31 19:44 ` [PATCH 4/7] uprobes/x86: Kill the "ia32_compat" check in handle_riprel_insn(), remove "mm" arg Oleg Nesterov
2014-04-01 3:10 ` Masami Hiramatsu
2014-04-03 16:33 ` Srikar Dronamraju
2014-03-31 19:44 ` [PATCH 5/7] uprobes/x86: Gather "riprel" functions together Oleg Nesterov
2014-04-01 3:21 ` Masami Hiramatsu
2014-04-02 19:53 ` Jim Keniston
2014-04-03 19:50 ` Oleg Nesterov
2014-03-31 19:44 ` [PATCH 6/7] uprobes/x86: move the UPROBE_FIX_{RIP,IP,CALL} code at the end of pre/post hooks Oleg Nesterov
2014-04-01 3:24 ` Masami Hiramatsu
2014-04-03 16:34 ` Srikar Dronamraju
2014-03-31 19:44 ` [PATCH 7/7] uprobes/x86: Introduce uprobe_xol_ops and arch_uprobe->ops Oleg Nesterov
2014-04-01 6:52 ` Masami Hiramatsu
2014-04-01 14:44 ` Oleg Nesterov
2014-04-01 15:01 ` Oleg Nesterov
2014-04-02 19:46 ` Jim Keniston
2014-04-03 19:49 ` Oleg Nesterov
2014-04-02 19:58 ` [PATCH 0/7] uprobes/x86: introduce " Jim Keniston
2014-04-03 20:00 ` [PATCH 8-9/7] " Oleg Nesterov
2014-04-03 20:00 ` [PATCH 8/7] uprobes/x86: Send SIGILL if arch_uprobe_post_xol() fails Oleg Nesterov
2014-04-03 20:01 ` [PATCH 9/7] uprobes/x86: Teach arch_uprobe_post_xol() to restart if possible Oleg Nesterov
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=20140403163219.GA4882@linux.vnet.ibm.com \
--to=srikar@linux.vnet.ibm.com \
--cc=ananth@in.ibm.com \
--cc=dave.long@linaro.org \
--cc=dvlasenk@redhat.com \
--cc=fche@redhat.com \
--cc=jkenisto@us.ibm.com \
--cc=jlebon@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=masami.hiramatsu.pt@hitachi.com \
--cc=mingo@elte.hu \
--cc=oleg@redhat.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.