[Top] [All Lists]

Re: [PATCH -v5 10/11] tracing: add function graph tracer support for MIP

Subject: Re: [PATCH -v5 10/11] tracing: add function graph tracer support for MIPS
From: Steven Rostedt <>
Date: Mon, 26 Oct 2009 13:11:19 -0400
Cc:,, Thomas Gleixner <>, Ralf Baechle <>, Nicholas Mc Guire <>, Richard Sandiford <>, David Daney <>, Adam Nemet <>, Patrik Kluba <>
In-reply-to: <1256576225.5642.244.camel@falcon>
Organization: Kihon Technologies Inc.
Original-recipient: rfc822;
References: <> <> <> <> <> <> <> <> <> <> <> <> <1256573467.5642.214.camel@falcon> <> <1256576225.5642.244.camel@falcon>
On Tue, 2009-10-27 at 00:57 +0800, Wu Zhangjin wrote:

> > I would be even more paranoid, and make sure each of those stores, store
> > into sp.
> get it :-)
> (I need to be more paranoid too, otherwise, Steven will not accept my
> patches!)

Sure I would accept them. I don't know of any MIPS boxes that Linus
runs. So I'm not afraid of crashing his boxes with these patches ;-)

> > > 
> > > We need to really stop before ftrace_push_return_trace to avoid messing
> > > with the stack :-) but if we have stopped the tracer, is it important to
> > > mess with the stack or not?
> > 
> > The ftrace_push_return_trace does not test if the trace stopped, that is
> > expected to be done by the caller. If you mess with the stack set up,
> > you will crash the box. Remember, before the failure, you could have
> > already replaced return jumps. Those will still be falling back to the
> > return_to_handler. If you mess with the stack, but don't update the
> > return, the other returns will be out of sync and call the wrong return
> > address.
> > 
> As you can see, after stopping the function graph tracer(here the function is 
> non-leaf)
> with ftrace_graph_stop() in ftrace_get_parent_addr(), I return the old 
> parent_addr,
> this is only the stack address in the stack space of ftrace_graph_caller, 
> which means
> that, I never touch the real stack address of the non-leaf function, and it 
> will not trap
> into the return_to_handler hooker 'Cause the non-leaf function will load it's 
> own normal
> return address from it's own stack, and then just return back normally.

But then you should not be calling the push function. That will still
push onto the graph stack.

The function graph tracer keeps a separate return stack
(current->ret_stack). This is what holds the return addresses.

(normal operation)

  jalr _mcount
           push ra onto ret_stack
           replace ra with return_to_handler

  jr ra  --> return_to_handler


   pop ret_stack, have original ra
   jr original_ra

Now what happens if we fail a call but still push to ret_stack

  jalr _mcount

          push ra onto ret_stack
          replace ra with return_to_handler

  jalr func2

      jalr _mcount

          push ra onto ret_stack  <<-- this is wrong!
          keep original ra

      jr ra << does not call tracer function!!!

  jr ra  << goes to return_to_handler


   pop ra from ret_stack <<--- has func2 ra not func1 ra!!

jr func1_ra

**** CRASH ****

Make sense?

-- Steve


<Prev in Thread] Current Thread [Next in Thread>