]> err.no Git - linux-2.6/commitdiff
[PARISC] Fix do_gettimeofday() hang
authorJames Bottomley <jejb@parisc-linux.org>
Sat, 24 Jun 2006 16:05:18 +0000 (16:05 +0000)
committerKyle McMartin <kyle@hera.kernel.org>
Tue, 27 Jun 2006 23:28:45 +0000 (23:28 +0000)
Apparently gettimeoffset can return small negative values (usually in
the 100us range).  If xtime.tv_nsec is accidentally less than this,
though (a fortunately unlikely event) it triggers the loop forever.

I've added a test and correct adjustment for this case.  It has a
warning printk in there which I'd like to leave for the time being
just in case this problem implicates some other part of the kernel.

Signed-off-by: James Bottomley <jejb@parisc-linux.org>
Signed-off-by: Kyle McMartin <kyle@parisc-linux.org>
arch/parisc/kernel/time.c

index 594930bc4bcf6d3df7231e0545bdbfbf5bb3842b..eb35e1c0bb532b679b660351fc5e28db1e6ee8b8 100644 (file)
@@ -157,8 +157,22 @@ do_gettimeofday (struct timeval *tv)
                usec += (xtime.tv_nsec / 1000);
        } while (read_seqretry_irqrestore(&xtime_lock, seq, flags));
 
-       while (usec >= 1000000) {
-               usec -= 1000000;
+       if (unlikely(usec > LONG_MAX)) {
+               /* This can happen if the gettimeoffset adjustment is
+                * negative and xtime.tv_nsec is smaller than the
+                * adjustment */
+               printk(KERN_ERR "do_gettimeofday() spurious xtime.tv_nsec of %ld\n", usec);
+               usec += USEC_PER_SEC;
+               --sec;
+               /* This should never happen, it means the negative
+                * time adjustment was more than a second, so there's
+                * something seriously wrong */
+               BUG_ON(usec > LONG_MAX);
+       }
+
+
+       while (usec >= USEC_PER_SEC) {
+               usec -= USEC_PER_SEC;
                ++sec;
        }