lk/linux-kernel-test
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

[PARISC] Fix do_gettimeofday() hang

Browse Source 
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>
This commit is contained in:
James Bottomley
2006-06-24 16:05:18 +00:00
committed by Kyle McMartin
parent 6e1b9585aa
commit 61c340166d
1 changed files with 16 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

18
arch/parisc/kernel/time.c
View File

@@ -157,8 +157,22 @@ do_gettimeofday (struct timeval *tv)
usec += (xtime.tv_nsec / 1000); usec += (xtime.tv_nsec / 1000);
} while (read_seqretry_irqrestore(&xtime_lock, seq, flags)); } while (read_seqretry_irqrestore(&xtime_lock, seq, flags));
while (usec >= 1000000) { if (unlikely(usec > LONG_MAX)) {
usec -= 1000000; /* 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; ++sec;
} }