Re: [patch] hrtimers debug patch

[Ingo Molnar]

* Michal Piotrowski <michal.k.k.piotrowski@xxxxxxxxx> wrote:

> Stardust is down, console log and config attached.

thanks! I have stared at hrtimer.c a few more hours and the good news is 
that i found a narrow SMP race. The bad news is that i dont think it 
could explain your bug symptoms: the worst-case effect of the race 
should be an incorrect timeout on the current CPU - not a KTIME_MAX 
thing like your logs show.

But maybe i didnt think through the effects of the bug well enough, and 
your box has a HT CPU, with HT CPUs being pretty good at triggering 
narrow SMP races - so maybe we are lucky? Fix attached below. Patch is 
build and boot-tested.

	Ingo

------------------>
Subject: [patch] hrtimers: fix reprogramming SMP race
From: Ingo Molnar <mingo@xxxxxxx>

hrtimer_start() incorrectly set the 'reprogram' flag to 
enqueue_hrtimer(), which should only be 1 if the hrtimer is queued to 
the current CPU.

doing otherwise could result in a reprogramming of the current CPU's 
clockevents device, with a timer that is not queued to it - resulting in 
a bogus next expiry value.

Signed-off-by: Ingo Molnar <mingo@xxxxxxx>
Needs-to-be-tested-by: Michal Piotrowski <michal.k.k.piotrowski@xxxxxxxxx>
---
 kernel/hrtimer.c |    7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

Index: linux/kernel/hrtimer.c
===================================================================
--- linux.orig/kernel/hrtimer.c
+++ linux/kernel/hrtimer.c
@@ -844,7 +844,12 @@ hrtimer_start(struct hrtimer *timer, kti
 
 	timer_stats_hrtimer_set_start_info(timer);
 
-	enqueue_hrtimer(timer, new_base, base == new_base);
+	/*
+	 * Only allow reprogramming if the new base is on this CPU.
+	 * (it might still be on another CPU if the timer was pending)
+	 */
+	enqueue_hrtimer(timer, new_base,
+			new_base->cpu_base == &__get_cpu_var(hrtimer_bases));
 
 	unlock_hrtimer_base(timer, &flags);
 
-
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/