tracing, sched: mark preempt_schedule() notrace

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 hardly happens, but marking preempt_schedule() notrace makes it safer.

One interesting thing is that preempt_schedule() is in the blacklist of kprobe subsystem. "__kprobes" implies "notrace". But preempt_schedule() cannot be marked __kprobes for it has been marked __sched. It is in the blacklist makes me consider this: should it be marked "notrace" -- YES.

Signed-off-by Lai Jiangshan <[email protected]>

---

kernel/sched.c +1 -1

index 5184580..2e9e209 100644
@@ -5534,7 +5534,7 @@ out:
  * off of preempt_enable. Kernel preemptions off return from interrupt
  * occur there and call schedule directly.
  */
-asmlinkage void __sched preempt_schedule(void)
+asmlinkage void __sched notrace preempt_schedule(void)
 {
 	struct thread_info *ti = current_thread_info();
 

Quoted 10 lines · Lai Jiangshan

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.

Quoted 9 lines · Lai Jiangshan

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.

Quoted 18 lines · Frederic Weisbecker

Quoted 9 lines · Lai Jiangshan

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.

Quoted 1 line

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.