[lkml]   [1996]   [Sep]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectJiffies 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;

while ((timer = != &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;

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)
if (!(mask & timer_active))
if (tp->expires > jiffies)
timer_active &= ~mask;

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.
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",

* 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",
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.


 \ /
  Last update: 2005-03-22 13:37    [W:0.053 / U:1.304 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site