Re: [patch] hrtimers debug patch

Ingo Molnar
2007-03-26T17:06:48Z

* Michal Piotrowski <michal.k.k.piotrowski@gmail.com> 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@elte.hu>

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@elte.hu>
Needs-to-be-tested-by: Michal Piotrowski <michal.k.k.piotrowski@gmail.com>
---
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);