Re: [ANNOUNCE] 2.6.15-rc5-hrt2 - hrtimers based high resolution patches

[Ingo Molnar <mingo@elte.hu>]

* Steven Rostedt <rostedt@goodmis.org> wrote:

> Thomas and Ingo,
> 
> I found a bug in 2.6.15-rc5-rt1 that was due to a race in the hrtimers 
> code.  This bug is most likely in the vanilla hrtimers code as well.
> 
> I added a HRTIMER_RUNNING state because there's a moment in the 
> run_hrtimer_queues that turns interrupts on and releases the base 
> lock. In this time, a remove_hrtimer can be called while the state is 
> still HRTIMER_PENDING_CALLBACK, but it has been removed off the list.  
> The remove_hrtimer will then try to remove this again.
> 
> Since I couldn't think of which state to use, I created the 
> HRTIMER_RUNNING, and used that instead.
> 
> I have a program (a simple jitter test) that, with out the patch, 
> reliably crashes the 2.6.15-rc5-rt1 on a slow UP machine.  With the 
> patch, it runs solidly, so I know this is the reason for the crash.

hm, in that case it should be base->running that protects against this 
case. Did you run an UP PREEMPT_RT kernel? In that case could you check 
whether the fix below resolves the crash too?

	Ingo

Index: linux/kernel/hrtimer.c
===================================================================
--- linux.orig/kernel/hrtimer.c
+++ linux/kernel/hrtimer.c
@@ -118,7 +118,7 @@ static DEFINE_PER_CPU(struct hrtimer_bas
  * Functions and macros which are different for UP/SMP systems are kept in a
  * single place
  */
-#ifdef CONFIG_SMP
+#if defined(CONFIG_SMP) || defined(PREEMPT_RT)
 
 #define set_curr_timer(b, t)		do { (b)->curr_timer = (t); } while (0)