Messages in this thread | | | Date | Wed, 19 Aug 2009 10:33:37 +0800 | From | Lai Jiangshan <> | Subject | Re: [PATCH] tracing, sched: mark preempt_schedule() notrace |
| |
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).
It hardly happen ... This doesn't mean it'll never happen.
> 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. > >
It's not normal behavior, preempt_schedule() will not call preempt_schedule() recursively in any situation when trace is off.
Here, preempt_schedule() is called from __trace_graph_return() when trace_function_graph is on.
preempt_schedule() __trace_graph_return() preempt_schedule() __trace_graph_return() ....
So, it's a real tracing recursion. It hurts the stack.
| |