Messages in this thread |  | | Date | Mon, 9 Sep 1996 12:54:30 -0400 (EDT) | From | Tyson D Sawyer <> | Subject | Jiffies overflow |
| |
There was a thread a short while back about what would happen if jiffies overflowed. The conclusion I got from the thread is that the kernel did deal with the over flow properly because it looked at differences.
As part of a development project I just spent a bit of time looking at the timer code in linux/kernel/sched.c and found that in most of the code that I was looking at, overflow is not considered. Note the two functions below:
static inline void run_timer_list(void) { struct timer_list * timer;
cli(); while ((timer = timer_head.next) != &timer_head && timer->expires <= jif fies) { void (*fn)(unsigned long) = timer->function; unsigned long data = timer->data; timer->next->prev = timer->prev; timer->prev->next = timer->next; timer->next = timer->prev = NULL; sti(); fn(data); cli(); } sti(); }
static inline void run_old_timers(void) { struct timer_struct *tp; unsigned long mask;
for (mask = 1, tp = timer_table+0 ; mask ; tp++,mask += mask) { if (mask > timer_active) break; if (!(mask & timer_active)) continue; if (tp->expires > jiffies) continue; timer_active &= ~mask; tp->fn(); sti(); } }
The expires values are compared directly to jiffies. I also noticed that if this gets fixed, the Comtrol RocketPort driver will break due to the way it sets its expires value only once during initialization:
/* * The module "startup" routine; it's run when the module is loaded. */ int init_module( void) { int i, retval, pci_boards_found, isa_boards_found; int reserved_controller = 0;
printk("Rocketport device driver module, version %s, %s\n", ROCKET_VERSION, ROCKET_DATE);
/* * Set up the timer channel. If it is already in use by * some other driver, give up. */ if (timer_table[COMTROL_TIMER].fn) { printk("rocket.o: Timer channel %d already in use!\n", COMTROL_TIMER); return -EBUSY; } timer_table[COMTROL_TIMER].fn = rp_do_poll; timer_table[COMTROL_TIMER].expires = 0; [...]
Either I'm being stupid (which is known to happen from time to time) or there may be a significant hic-up when someone gets jiffies to overflow.
As I see it, a timer that is set to jiffies+someval, where someval causes an overflow, will be called on the next timer cycle instead of waiting until it is scheduled. For somethings this may not be harmful beyond wasting CPU cycles. Those that depend on the delay actually taking place will break.
Ty
|  |