All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sandeepa Prabhu <sandeepa.prabhu@linaro.org>
To: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: Ingo Molnar <mingo@kernel.org>,
	Ananth N Mavinakayanahalli <ananth@in.ibm.com>,
	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: Fri, 6 Dec 2013 12:24:29 +0530	[thread overview]
Message-ID: <CA+b37P3BywWsuNgjVfvxxK2acAbV7qd6R5UJd1UEYdHHuQ56ag@mail.gmail.com> (raw)
In-Reply-To: <52A16D49.9050105@hitachi.com>

>> I am not sure if this question is related, uprobes or ftrace code does
>> not  define __kprobes, so is it safe to place kprobe on uprobes or
>> ftrace code?
>
> Yes, it is "safe" in qualitative meaning. But for ftrace code, it could
> give a performance impact by miss-hitting. Since uprobe is independent
> from kprobe, it should work.
>
>> Is it expected from arch code to support such cases?
>
> Yes, the arch dependent implementation is the key. If it shares some
> code which can be called from miss-hit path, it should be blacklisted.
well, isn't the blacklist only for those routines that can not be
handled or may crash kernel, like the code sections called from
exception kprobes exception handlers etc?
suppose if the probe on routine can miss-hit (probes re-cursing) but
can be handled, it's only a quantitative issue (i.e. performance
impact) so it should be *user's* problem right? I mean, as you said
earlier about having white-list or a performance gatekeeper
(systemtap), one can avoid such cases by white list or removing
miss-hit probes dynamically.  But a blacklisting a symbol means
placing a probe on that *can not be handled* and can crash the system,
is it correct?

Thanks,
Sandeepa

>
> Thank you,
>
> --
> Masami HIRAMATSU
> IT Management Research Dept. Linux Technology Center
> Hitachi, Ltd., Yokohama Research Laboratory
> E-mail: masami.hiramatsu.pt@hitachi.com
>
>

  reply	other threads:[~2013-12-06  6:54 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
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 [this message]
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=CA+b37P3BywWsuNgjVfvxxK2acAbV7qd6R5UJd1UEYdHHuQ56ag@mail.gmail.com \
    --to=sandeepa.prabhu@linaro.org \
    --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=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.