On Mon, 2007-03-05 at 08:56 -0800, Daniel Walker wrote: > I've only seen this on x86_64 . > > The vsyscall state only gets updated when a timer interrupts comes in . So > if the time is set long before the next timer, there will be a period when > a gettimeofday() won't reflect the correct time. > > I added an explicit update_vsyscall() during the settimeofday(), that way > the vsyscall state doesn't get stale. > > Any thought John?
Oh! Yes, very good catch, Daniel! Thanks so much! -john > Signed-Off-By: Daniel Walker <[EMAIL PROTECTED]> Acked-by: John Stultz <[EMAIL PROTECTED]> > --- > kernel/timer.c | 2 ++ > 1 file changed, 2 insertions(+) > > Index: linux-2.6.20/kernel/timer.c > =================================================================== > --- linux-2.6.20.orig/kernel/timer.c > +++ linux-2.6.20/kernel/timer.c > @@ -861,6 +861,8 @@ int do_settimeofday(struct timespec *tv) > clock->error = 0; > ntp_clear(); > > + update_vsyscall(&xtime, clock); > + > write_sequnlock_irqrestore(&xtime_lock, flags); > > /* signal hrtimers about time change */ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/