Commit:     62f0f61e6673e67151a7c8c0f9a09c7ea43fe2b5
Parent:     f194d132e4971111f85c18c96067acffb13cee6d
Author:     Thomas Gleixner <[EMAIL PROTECTED]>
AuthorDate: Fri Dec 7 19:16:17 2007 +0100
Committer:  Ingo Molnar <[EMAIL PROTECTED]>
CommitDate: Fri Dec 7 19:16:17 2007 +0100

    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
    Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>
    Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
 kernel/hrtimer.c |    8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/kernel/hrtimer.c b/kernel/hrtimer.c
index 22a2514..e65dd0b 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)
                tim = ktime_add(tim, base->resolution);
+               /*
+                * 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;
To unsubscribe from this list: send the line "unsubscribe git-commits-head" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at

Reply via email to