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

Steven Rostedt
2009-10-26T17:11:18Z

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)

func1
jalr _mcount

push ra onto ret_stack
replace ra with return_to_handler

jr ra --> return_to_handler

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

func1
jalr _mcount

(success)
push ra onto ret_stack
replace ra with return_to_handler

jalr func2

func2
jalr _mcount

(failed)
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

return_to_handler

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

jr func1_ra

**** CRASH ****

Make sense?

-- Steve