[lkml]   [2005]   [Aug]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Patch in this message
SubjectRe: 2.6.13-rc6-rt9
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 <>

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:
+ * 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);
static __cacheline_aligned_in_smp DECLARE_MUTEX(max_mutex);
* 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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-08-19 17:39    [W:0.077 / U:1.028 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site