On Mon, 2013-05-13 at 17:56 +0800, Li Zhong wrote: > > All this before schedule_user() was able to call user_exit() and take us > > out of dynamic tick user context. > > Maybe we could just disable function trace for schedule_user()? > > It seems that function trace might use RCU, at least in __schedule() > when calling preempt_enable(), and if preemption is really enabled.
There is a small use of rcu scheduling (preempt disable/enable) in function tracing. One is for perf and dynamic call traces and some hash code (multiple users of the function tracer). But those are the unique cases, and I really do not want to remove this function just for the non common case. Function tracing has proven extremely useful in debugging RCU and context tracking. By adding notrace, it's a lost cause. Not to mention, adding trace_printk() there will break it too, and that does not use any RCU but still disables preemption because the writing to the ring buffer requires staying on the same CPU. > > user_exit() is used to allow RCU usage after that (with rcu_user_exit). > RCU usage is not allowed before that because cpu is in user eqs. And if > function trace needs use RCU, then it seems user_exit() itself or its > callers couldn't be function traced. And it can't be debugged either. I can probably black list those functions manually, such that only the main function tracer can trace it, all others will not. In otherwords, I can have it such that function tracer will not trace those functions for perf, dynamic function tracers, or anything that requires changing the function list. I could probably also add a heavier weight synchronize_sched() that even synchronizes cpus in userspace. > > If __schedule() in preempt_enable() is the only place function trace > uses RCU, then after converting to schedule_preempt_user(), it is safe > as irqs are disabled for __schedule() to happen. But user_exit() itself > and some other callers might still need function trace be disabled. The above makes no sense to me. function tracing didn't break, but the user_exit() did because of a preemption in the wrong place, as there was no protection there to prevent an unnecessary preemption. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
