Messages in this thread |  | | Date | Wed, 21 Aug 1996 08:23:48 +0200 (MET DST) | From | Ingo Molnar <> | Subject | Re: Jiffies Wraparound (was Re: interrupt counts) |
| |
On Tue, 20 Aug 1996, Theodore Y. Ts'o wrote:
> 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
|  |