Messages in this thread | | | Date | Sat, 07 Dec 2013 08:25:36 +0900 | From | Masami Hiramatsu <> | Subject | Re: [PATCH -tip v4 0/6] kprobes: introduce NOKPROBE_SYMBOL() and fixes crash bugs |
| |
(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
| |