[lkml]   [2013]   [Dec]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [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

     \ /
      Last update: 2013-12-07 02:41    [W:2.910 / U:0.000 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site