lkml.org 
[lkml]   [2009]   [Aug]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [TOOL] kprobestest : Kprobe stress test tool
    Frederic Weisbecker wrote:
    >> Most of them can be fixed just by adding __kprobes.
    >> Some of them which are already in the another section, kprobes
    >> should check the symbols are in the section.
    >
    >
    > You mean the blacklist?
    >
    > I also fear that putting bad kprobed functions into the kprobe
    > section or into the blacklist may hide some kprobe internal bugs.
    >
    > Doing so is indeed mandatory for functions that trigger tracing
    > recursion of things like that, but what if kprobe has an internal
    > bug that only triggers while probe a certain class of function.
    >
    > Ie: it would be nice to identify the reason of the crash for
    > each culprit in these lists.
    >
    > That may even help to find the others in advance.

    Indeed, actually I've found some bugs while making jump-optimization
    patches by using this stress test.
    But some of them are obviously what we just forget to add __kprobes,
    since those will be called from kprobes int3 handling functions.

    And also, many lock-related code has been changed. I think
    kprobes should use raw_*_lock, or prohibit to probe lock monitoring
    functions like lockdep, because it will cause recursive call.

    >
    > Also kprobes seems to be a very fragile feature (that's what
    > this selftest unearthes at least for me).
    > And it really needs a recursion detection that stops every kprobing
    > while reaching a given threshold of recursion. Something
    > that would dump the stack and the falling kprobe structure.

    Hmm, kprobes already has recursion detection(kp->nmiss), so
    maybe, we can check it.

    >
    > That would avoid such hard lockups and also help to identify
    > the dangerous symbols to probe.
    >
    >
    >
    >>> The problem is that I don't have any serial line in this
    >>> box then I can't catch any crash log.
    >>> My K7 testbox also died in my arms this afternoon.
    >>>
    >>> But I still have two other testboxes (one P2 and one P3),
    >>> hopefully I could reproduce the problem in these boxes
    >>> in which I can connect a serial line.
    >>
    >> Thank you for helping me to find it!
    >>
    >>> I've pushed your patches in the following git tree:
    >>>
    >>> git://git.kernel.org/pub/scm/linux/kernel/git/fgrederic/random-tracing.git \
    >>> tracing/kprobes
    >>>
    >>> So you can send patches on top of this one.
    >>
    >> Great! I've found another trivial bugs, so I'll fix those on it.
    >
    > Cool :)
    >
    > Btw, here is the result of your stress test in a PIII (attaching the log
    > and the config).

    Thanks, I'll check that.

    Thank you,

    --
    Masami Hiramatsu

    Software Engineer
    Hitachi Computer Products (America), Inc.
    Software Solutions Division

    e-mail: mhiramat@redhat.com



    \
     
     \ /
      Last update: 2009-08-21 03:01    [from the cache]
    ©2003-2014 Jasper Spaans. hosted at Digital Ocean