* Steven Rostedt <[email protected]> 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)
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
