[PATCH] Fix a NO_IDLE_HZ timer bug
authorZachary Amsden <zach@vmware.com>
Sat, 20 May 2006 22:00:24 +0000 (15:00 -0700)
committerLinus Torvalds <torvalds@g5.osdl.org>
Sun, 21 May 2006 19:59:21 +0000 (12:59 -0700)
commit0662b71322e211dba9a4bc0e6fbca7861a2b5a7d
treebffce074929b6a36b7b1e00a485df7a5fe95cc22
parent8b1ea24c6cc529f6860c458b1c0872f22e74c950
[PATCH] Fix a NO_IDLE_HZ timer bug

Under certain timing conditions, a race during boot occurs where timer
ticks are being processed on remote CPUs.  The remote timer ticks can
increment jiffies, and if this happens during a window when a timeout is
very close to expiring but a local tick has not yet been delivered, you can
end up with

1) No softirq pending
2) A local timer wheel which is not synced to jiffies
3) No high resolution timer active
4) A local timer which is supposed to fire before the current jiffies value.

In this circumstance, the comparison in next_timer_interrupt overflows,
because the base of the comparison for high resolution timers is jiffies,
but for the softirq timer wheel, it is relative the the current base of the
wheel (jiffies_base).

Signed-off-by: Zachary Amsden <zach@vmware.com>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Oleg Nesterov <oleg@tv-sign.ru>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
kernel/timer.c