Re: [RFC][PATCH] ftrace: Use schedule_on_each_cpu() as a heavysynchronize_sched()

[Steven Rostedt]

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/