lkml.org 
[lkml]   [2013]   [Dec]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    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
    E-mail: masami.hiramatsu.pt@hitachi.com




    \
     
     \ /
      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