On Tue, 2013-06-04 at 13:03 +0200, Frederic Weisbecker wrote: > If ftrace were to use rcu_dereference_sched() instead of > rcu_dereference_raw(), I guess > the issue would have been detected before. But I guess we want to avoid that > for > tracing recursion?
It's been detected before, just ignored as most of ftrace function tracing has permanent objects and the synchronization doesn't really matter for them. But for perf and SystemTap that uses dynamically created ftrace_ops and needs to free them, it does make a difference. Something I knew needed to be fixed but never got around to it as the race is extremely tight (and requires root user trying to trigger it). I haven't been ably to trigger the race, but in theory it's there. Note the checks that rcu_dereference_sched() has to test for these kinds of things would cause ftrace to live lock the system if it had used it. In fact, I had to make a rcu_dereference_raw_notrace() to prevent ftrace locking up the system when full rcu debugging is enabled. -- 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/
