On Fri, 2005-08-19 at 09:00 -0400, Steven Rostedt wrote: > On Fri, 2005-08-19 at 02:39 -0400, Steven Rostedt wrote:
> I haven't thought of a good way yet to solve the race condition with > dependent sleeper. (Except by turning off CONFIG_WAKEUP_TIMING :-) > OK, I found one simple solution. The problem stems from max_mutex being grabbed. Since this uses the RT locks, and since tracing shouldn't really care about PI and all that, I switched this to a compat_semaphore, but only if CONFIG_WAKEUP_TIMING is set. This seems to get rid of this race condition that I have. I found more bugs, but for now this message is about this specific race. -- Steve Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]> Index: linux_realtime_ernie/kernel/latency.c =================================================================== --- linux_realtime_ernie/kernel/latency.c (revision 297) +++ linux_realtime_ernie/kernel/latency.c (working copy) @@ -102,7 +102,19 @@ /* * Track maximum latencies and save the trace: */ +#ifdef CONFIG_WAKEUP_TIMING +/* + * The WAKEUP_TIMING has a race condition, since + * trace_stop_sched_switched might be called with run queue locks held + * which eventually calls down_trylock. + * But the RT version of down_trylock grabs a bunch of locks that + * are used by rt_up. rt_up can call wake_up_process which + * eventually grabs a run queue lock. + */ +static __cacheline_aligned_in_smp COMPAT_DECLARE_MUTEX(max_mutex); +#else static __cacheline_aligned_in_smp DECLARE_MUTEX(max_mutex); +#endif /* * Sequence count - we record it when starting a measurement and * skip the latency if the sequence has changed - some other section - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
