> Something that would probably be a very good thing to do is during the
> 2.1 development cycle, change the kernel so that jiffies *always*
> overflows after 5 minutes. It would be a very good way of making sure
> that we can always handle the overflows correctly, and it's also a good
> way to keep future device driver developers on the straight and narrow.
There are about 200 lines in the kernel where "jiffies" is directly
compared to another variable. Code like "timeout<=jiffies" is broken, from
the wraparound point of view. Those 200+ lines are scattered across 75
files. Most drivers use "jiffies" for timing hardware access. Such error
detection code is hard to test, the even such a 5 minutes wraparound
test wont find them.
IMHO, we either should forget about it and wait for Merced or anything
else to move us out of the 32 bit world ... or we should completely avoid
comparing "jiffies" to variables. We could do this the following way:
#define IS_TIMED_OUT(timeout) (jiffies>timeout) || \
(timeout-jiffies>MAX_JIFFIES/2)
This way our "timers" could run from 0 up to MAX_JIFFIES/2, and they
would never break at a wraparound. This comparison operation is a bit more
expensive than the normal one, but it's still very fast. Much faster than
an artificial 64 bit counter on 32 bit platforms.
and broken code is easy to detect:
grep -w jiffies *.c | grep -E '>|<' | grep -ve '->'
Btw, are the usual kernel timers insensitive to lost jiffies at
wraparound? If we jump 2 jiffies right when we wraparound, then the "="
operation fails to detect a timeout. This again might be a 5000 years bug
:(
-- mingo