diff options
| author | Thomas Gleixner <tglx@linutronix.de> | 2007-12-07 19:16:17 +0100 |
|---|---|---|
| committer | Ingo Molnar <mingo@elte.hu> | 2007-12-07 19:16:17 +0100 |
| commit | 62f0f61e6673e67151a7c8c0f9a09c7ea43fe2b5 (patch) | |
| tree | c41cc826e53b7ce726e6f343a0ab72ad7e058ca4 | |
| parent | f194d132e4971111f85c18c96067acffb13cee6d (diff) | |
| download | kernel-common-62f0f61e6673e67151a7c8c0f9a09c7ea43fe2b5.tar.gz kernel-common-62f0f61e6673e67151a7c8c0f9a09c7ea43fe2b5.tar.bz2 kernel-common-62f0f61e6673e67151a7c8c0f9a09c7ea43fe2b5.zip | |
hrtimers: avoid overflow for large relative timeouts
Relative hrtimers with a large timeout value might end up as negative
timer values, when the current time is added in hrtimer_start().
This in turn is causing the clockevents_set_next() function to set an
huge timeout and sleep for quite a long time when we have a clock
source which is capable of long sleeps like HPET. With PIT this almost
goes unnoticed as the maximum delta is ~27ms. The non-hrt/nohz code
sorts this out in the next timer interrupt, so we never noticed that
problem which has been there since the first day of hrtimers.
This bug became more apparent in 2.6.24 which activates HPET on more
hardware.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
| -rw-r--r-- | kernel/hrtimer.c | 8 |
1 files changed, 8 insertions, 0 deletions
diff --git a/kernel/hrtimer.c b/kernel/hrtimer.c index 22a25142e4cf..e65dd0b47cdc 100644 --- a/kernel/hrtimer.c +++ b/kernel/hrtimer.c @@ -850,6 +850,14 @@ hrtimer_start(struct hrtimer *timer, ktime_t tim, const enum hrtimer_mode mode) #ifdef CONFIG_TIME_LOW_RES tim = ktime_add(tim, base->resolution); #endif + /* + * Careful here: User space might have asked for a + * very long sleep, so the add above might result in a + * negative number, which enqueues the timer in front + * of the queue. + */ + if (tim.tv64 < 0) + tim.tv64 = KTIME_MAX; } timer->expires = tim; |