This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [PATCH -tip v4 0/6] kprobes: introduce NOKPROBE_SYMBOL() and fixes crash bugs
- From: Masami Hiramatsu <masami dot hiramatsu dot pt at hitachi dot com>
- To: Sandeepa Prabhu <sandeepa dot prabhu at linaro dot org>
- Cc: Ingo Molnar <mingo at kernel dot org>, Ananth N Mavinakayanahalli <ananth at in dot ibm dot com>, x86 at kernel dot org, lkml <linux-kernel at vger dot kernel dot org>, "Steven Rostedt (Red Hat)" <rostedt at goodmis dot org>, systemtap at sourceware dot org, "David S. Miller" <davem at davemloft dot net>
- Date: Sat, 07 Dec 2013 08:25:36 +0900
- Subject: Re: [PATCH -tip v4 0/6] kprobes: introduce NOKPROBE_SYMBOL() and fixes crash bugs
- Authentication-results: sourceware.org; auth=none
- References: <20131204012841 dot 22118 dot 82992 dot stgit at kbuild-fedora dot novalocal> <20131204084551 dot GA31772 at gmail dot com> <529FBA71 dot 6070107 at hitachi dot com> <CA+b37P1ejFn4YJekJFOCe701mLTprqQi4KSyGV4S7QiVaC1=qA at mail dot gmail dot com> <52A16D49 dot 9050105 at hitachi dot com> <CA+b37P3BywWsuNgjVfvxxK2acAbV7qd6R5UJd1UEYdHHuQ56ag at mail dot gmail dot com>
(2013/12/06 15:54), Sandeepa Prabhu wrote:
>>> 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?
Yes, that's why the blacklist is needed.
> 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?
Yes, exactly that is what I meant. :)
The blacklist is only for avoiding such fundamental issue, therefore,
it strongly depends on the architecture code.
Thank you,
--
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@hitachi.com