Re: 2.6.13-rc6-rt9

[Steven Rostedt]

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 <rostedt@xxxxxxxxxxx>

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