Messages in this thread | | | Date | Wed, 19 Aug 2009 11:07:44 +0800 | From | Lai Jiangshan <> | Subject | Re: [PATCH] tracing, sched: mark preempt_schedule() notrace |
| |
Steven Rostedt wrote: > > 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. >
You're right, I forgot to read trace_graph_return(). trace_graph_return() protects itself from recursion.
Since there is no may-recursive trace_func_graph_ret_t. Just omit this patch. Sorry for bothered you all.
| |