Messages in this thread | ![/](/images/icornerl.gif) | | Date | Tue, 18 Aug 2009 12:28:47 -0400 (EDT) | From | Steven Rostedt <> | Subject | Re: [PATCH] tracing, sched: mark preempt_schedule() notrace |
| |
On Tue, 18 Aug 2009, Frederic Weisbecker wrote:
> On Tue, Aug 18, 2009 at 04:01:57PM +0800, Lai Jiangshan wrote: > > > > Current preempt_schedule() is not marked notrace. It may be > > infinite recursion in __trace_graph_return(). > > > > preempt_schedule() > > __trace_graph_return() > > ftrace_preempt_disable() (!!return false!!) > > ftrace_preempt_enable() > > preempt_enable_notrace() > > preempt_schedule() (need_resched() may be true again) > > > > It would happen in __trace_graph_return() , when preempt_schedule() > has finished its job. It's very unlikely the TIF_NEED_RESCHED is > set just after (because it has just been cleared). > But why not. In that case, preempt_schedule() is called again but it's > not a real tracing recursion. > > That seems like a normal behaviour actually.
In fact, this is actually something to be traced. I would not add a notrace to it. This is not saving anything, the trace_graph_return does not need to worry about stack overflow, since the return code already freed the stack.
-- Steve
| ![\](/images/icornerr.gif) |