=>From: Andrea Arcangeli <andrea@suse.de>
=>...
=>I reviewed the time-related stuff in 2.2.12 and I found potential SMP
=>races in the time-related syscalls. Basically the only problem is that the
=>time-syscalls are not protecting against each other. They are only
=>protecting themself against the timer irq. And this may lead to SMP
=>races.
=> [patch omitted]
I applied your patch against 2.3.18 and tried it out, but no luck. I
also tried protecting all reads of xtime (a multi-word structure)
with:
read_lock(&xtime_lock);
*dest = xtime;
read_unlock(&xtime_lock);
but that didn't do any good either: I still see gettimeofday()
returning values smaller than were previously returned from a
userspace program, and a prink() I put in arch/i386/kernel/time.c
shows many more (smaller) time backups.
In all cases, xntpd was not run (either during the boot process or
from the command line).
=>I can't reproduce
=>in any way here, but I am not sure I configured xntp hard enough to
=>trigger the race
Is there anybody near Los Angeles who would benefit from a look at my
machine? I'd be willing to take a road trip with it to show it to
somebody smarter than myself it it'll help... Or if somebody wants to
send me a ticket to Germany... :-)
regards,
d.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/