lkml.org 
[lkml]   [2012]   [Jun]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [RFC][PATCH 00/13 v2] kprobes/ftrace: Making ftrace usable for kprobes
    From
    Date
    On Wed, 2012-06-13 at 17:25 +0900, Masami Hiramatsu wrote:
    > (2012/06/13 7:43), Steven Rostedt wrote:
    > > If an arch supports passing of ftrace ops, it must also pass regs.
    > > But it does not need to support passing regs. By default
    > > an arch can just pass NULL. If it supports regs, then
    > > it can allow tools like kprobes to ask for regs. Otherwise the
    > > regs parameter should just be NULL.
    >
    > Hmm, by default, will the ftrace_ops be also NULL? or NULL only if
    > the arch doesn't support passing ftrace ops?
    > I mean, should the generic handler always check if ftrace_ops
    > isn't NULL before using it?

    Nope, ftrace_ops will always be set with the ops that registered it for
    the callback. As suppose to regs, ftrace_ops is created by the generic
    core code and is arch agnostic. With regs, that's very arch specific and
    if an arch does not support passing regs, there's nothing that the core
    code can do about it but pass a NULL pointer telling the callback
    "Sorry!".

    Currently there's a few things that an arch needs to do in the mcount
    handler to support full dynamic ftrace. One is to check the
    function_trace_stop variable is not set before calling the callback. If
    an arch does not support this, then ftrace will only let the callback be
    a generic function that does the check on behalf of the arch and then
    calls the normal routine.

    Now the arch also needs to support sending in the 3rd parameter the
    ftrace_ops. If it does not support this ftrace generic code will.
    Luckily, it already has code to do this. If more than one ftrace_ops is
    registered (even if they register to different functions), a generic
    handler is called that iterates through all the registered ftrace_ops to
    call their callbacks. It also checks if the ftrace_ops has registered
    the current function before calling it.

    Now if an arch does not pass the ftrace ops we simply call this list
    function instead. The list function already has access to what
    ftrace_ops is being used and passes that to the callback. Again, this is
    what must be done anyway if more than one ftrace_ops is registered to
    the function tracer.

    As this is another indirect call that must be made, I removed the old
    helper function that does the check against function_trace_stop variable
    and made the arch call the list code instead. The list code now does the
    check. If the arch does not support checking function_trace_stop, it
    most likely doesn't support passing ftrace_ops either.

    -- Steve




    \
     
     \ /
      Last update: 2012-06-13 13:42    [W:0.028 / U:0.832 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site