From: Josh Stone <jistone@redhat.com>
To: Ingo Molnar <mingo@kernel.org>,
Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>,
Sandeepa Prabhu <sandeepa.prabhu@linaro.org>,
x86@kernel.org, lkml <linux-kernel@vger.kernel.org>,
"Steven Rostedt (Red Hat)" <rostedt@goodmis.org>,
systemtap@sourceware.org, "David S. Miller" <davem@davemloft.net>
Subject: Re: [PATCH -tip v4 0/6] kprobes: introduce NOKPROBE_SYMBOL() and fixes crash bugs
Date: Thu, 12 Dec 2013 12:42:16 -0800 [thread overview]
Message-ID: <52AA1FA8.30709@redhat.com> (raw)
In-Reply-To: <20131212140347.GA17059@gmail.com>
On 12/12/2013 06:03 AM, Ingo Molnar wrote:
>> No, because the int3 already changes the original instruction.
>> This means that you cannot skip singlestep(or emulate) the
>> instruction which is copied to execution buffer (ainsn->insn),
>> even if you have such the flag.
>> So, kprobe requires the annotations on the singlestep path.
> I don't understand this reasoning.
>
> Lets assume we allow a probe to be inserted in the single-step path.
> Such a probe will be an INT3 instruction and if it hits we get a
> recursive INT3 invocation. In that case the INT3 handler should simply
> restore the original instruction and _leave it so_. There's no
> single-stepping needed - the probe is confused and must be discarded.
So if you restore the original instruction, then you're essentially
creating a dynamic blacklist for the singlestep path, right? I think
that's fine, as long as you still allow recursive probes elsewhere to
just singlestep and skip that occurrence.
It also helps with the inlining issues, since an inlined function
instance in the singlestep path can get dynamically blocked, while still
allowing inline instances elsewhere to be probed normally. Then you
don't have to force always/never inline decisions - whatever gcc decides
to do with inlines and static functions can be dealt with.
Josh
next prev parent reply other threads:[~2013-12-12 20:42 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-04 1:28 [PATCH -tip v4 0/6] kprobes: introduce NOKPROBE_SYMBOL() and fixes crash bugs Masami Hiramatsu
2013-12-04 1:28 ` [PATCH -tip v4 1/6] kprobes: Prohibit probing on .entry.text code Masami Hiramatsu
2013-12-04 1:28 ` [PATCH -tip v4 2/6] kprobes: Introduce NOKPROBE_SYMBOL() macro for blacklist Masami Hiramatsu
2013-12-04 1:28 ` [PATCH -tip v4 3/6] [BUGFIX] kprobes/x86: Prohibit probing on debug_stack_* Masami Hiramatsu
2013-12-04 1:28 ` [PATCH -tip v4 4/6] [BUGFIX] x86: Prohibit probing on native_set_debugreg Masami Hiramatsu
2013-12-04 1:28 ` [PATCH -tip v4 5/6] [BUGFIX] x86: Prohibit probing on thunk functions and restore Masami Hiramatsu
2013-12-04 1:28 ` [PATCH -tip v4 6/6] [RFC] kprobes/x86: Call exception handlers directly from do_int3/do_debug Masami Hiramatsu
2013-12-04 2:39 ` Steven Rostedt
2013-12-11 13:31 ` Jiri Kosina
2013-12-12 4:40 ` Masami Hiramatsu
2013-12-12 9:59 ` Jiri Kosina
2013-12-12 10:31 ` Masami Hiramatsu
2013-12-04 2:54 ` [PATCH -tip v4 0/6] kprobes: introduce NOKPROBE_SYMBOL() and fixes crash bugs Sandeepa Prabhu
2013-12-04 7:39 ` Masami Hiramatsu
2013-12-04 8:46 ` Sandeepa Prabhu
2013-12-04 23:32 ` Masami Hiramatsu
2013-12-04 8:45 ` Ingo Molnar
2013-12-04 23:27 ` Masami Hiramatsu
2013-12-05 10:21 ` Ingo Molnar
2013-12-06 2:34 ` Masami Hiramatsu
2013-12-10 15:28 ` Ingo Molnar
2013-12-11 2:12 ` Masami Hiramatsu
2013-12-11 13:34 ` Ingo Molnar
2013-12-12 6:02 ` Masami Hiramatsu
2013-12-12 14:03 ` Ingo Molnar
2013-12-12 20:42 ` Josh Stone [this message]
2013-12-13 5:34 ` Masami Hiramatsu
2013-12-13 6:06 ` Masami Hiramatsu
2013-12-16 10:53 ` Masami Hiramatsu
2013-12-05 13:08 ` Sandeepa Prabhu
2013-12-06 6:23 ` Masami Hiramatsu
2013-12-06 6:54 ` Sandeepa Prabhu
2013-12-06 23:25 ` Masami Hiramatsu
2013-12-05 14:49 ` Frank Ch. Eigler
2013-12-06 6:12 ` Masami Hiramatsu
2013-12-06 19:07 ` Frank Ch. Eigler
2013-12-06 23:19 ` Masami Hiramatsu
2013-12-07 1:32 ` Frank Ch. Eigler
2013-12-07 2:34 ` Masami Hiramatsu
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=52AA1FA8.30709@redhat.com \
--to=jistone@redhat.com \
--cc=ananth@in.ibm.com \
--cc=davem@davemloft.net \
--cc=linux-kernel@vger.kernel.org \
--cc=masami.hiramatsu.pt@hitachi.com \
--cc=mingo@kernel.org \
--cc=rostedt@goodmis.org \
--cc=sandeepa.prabhu@linaro.org \
--cc=systemtap@sourceware.org \
--cc=x86@kernel.org \
/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.