lkml.org 
[lkml]   [2011]   [Aug]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH 0/5][RFC] kprobes/ftrace: Have kprobes use ftrace on ftrace nops
    From
    Date
    On Thu, 2011-08-11 at 09:21 +0900, Masami Hiramatsu wrote:
    > Hi Steven,
    >
    > Thanks for this nice feature!
    >
    > (2011/08/11 1:22), Steven Rostedt wrote:
    > > Hi All,
    > >
    > > I started working on adding the -mfentry switch to ftrace, which
    > > allows us to remove the frame pointers requirement from function tracing
    > > as well as makes mcount (fentry) work just better.
    > >
    > > But when I did this in another branch, I noticed that I broke kprobes
    > > in its most common usage. The attaching a probe at the beginning of
    > > a function to use get to its parameters.
    > >
    > > So I started this branch. This branch is to have kprobes use ftrace
    > > directly when a probe is attached to a ftrace nop. Currently, kprobes
    > > will just error when that happens. With this patch set, it will hook
    > > into the ftrace infrastructure and use ftrace instead. This is more
    > > like an optimized probe as no breakpoints need to be set. A call to
    > > the function is done directly via the mcount trampoline. If ftrace
    > > pt_regs is implemented for an arch, kprobes gets this feature for free.
    >
    > I agreed this idea, this looks good to me too :)
    > With -fentry, this can improve dynamic trace events very much.
    >
    > BTW (OT), it seems that current kprobe data structure becomes a bit
    > fat. Maybe what we need is just a "holder of hooking handler" as
    > what ftrace provides, not a full storage data structure of copied
    > instrucutions. Perhaps, we'd better diet the kprobe structure for
    > transparency of hooking infrastructure.

    Sure, I can make the ftrace_ops field in kprobes dynamically allocated
    instead. That shouldn't be an issue.

    >
    > > The first patch is just a clean up that I need to push out to get rid
    > > of the annoying compile warning about initialized variables that
    > > gcc can't tell have been initialized.
    > >
    > > The next two patches have ftrace pass both the ftrace_ops structure
    > > and the pt_regs to the callback function that is registered with ftrace.
    > >
    > > The last two patches have kprobes interact with ftrace and use the
    > > ftrace infrastructure instead.
    > >
    > > I only did this for x86_64, and will do it for x86_32 and PPC64 if everyone
    > > agrees with this approach. Then I could find people to do it for other
    > > archs :)
    >
    > OK, I'll review this soon!

    Thanks!

    -- Steve




    \
     
     \ /
      Last update: 2011-08-11 02:37    [from the cache]
    ©2003-2014 Jasper Spaans. hosted at Digital Ocean