Re: [Q] jiffies overflow & timers.

From: Ihar 'Philips' Filipau
Date: Tue Nov 18 2003 - 09:13:08 EST


Richard B. Johnson wrote:

[ Very good lection on 2-complement arithmetics snipped. This is I beleive feature of C: (type) conversion say to compiler "forget about original data type - use this one". So this was misunderstanding on my side. And thanks for examples ;-) ]


It is state machine, it is event driven - there is nothing that can
yield CPU to someone else, because in first place it does not take CPU ;-)))
Right now it is run from tasklet - so ksoftirqd context.



If you are looping in a tasklet, waiting for something to happen, you
are "locked up" until the event which may never happen. If for some
"bad hardware that they won't fix" reason, you must loop, then you
need to create a kernel thread. If the hardware is good and you
decided to write a driver this way, then you need to re-think
what you are doing.


As I said this is network layer.
My hardware is good - we miss nothing ;-) [ After all it is made in room next to mine ;-))) ]

I have situations when layer needs to know that given time had passed - so if is there any other way to do it without timers - I will really appreciate for any advice.

The same stuff as in TCP/IP - after some time we need to tell that this connection timed-out. and TCP/IP uses timers for this: given routine will be called at specified jiffies, so e.g. handshake can be invalidated or data retransmission invoked.

In my case layer service routines will generate specially formated input for fsm - so fsm will know that given timer has expired and will take actions accordingly. Quite flexible - I enqueueing can be put into any context and just need to "tasklet_schedule( &layer_entry );" The same way skbs are passed to fsm. Pretty standard telecoms layer.


So to draw conclusion: ./kernel/timer.c: add_timer/del_timer/mod_timer are not protected against jiffies overflow. internal_add_timer() implicitely schedules items with expires < jiffies into the head, so they will be processed at next timer tick. (check 2.4.22 & 2.6.0test7)

Actually I beleive that here the same trick as for Y2K problem can be used:
if (expires < ULONG_MAX/2 && jiffies >= ULONG_MAX/2
&& (jiffies - expires) > ULONG_MAX/2)
assume_expires_has_overflown();
In any way, as you say, if someone sets the timer for time longer that ULONG_MAX/2 - this is most likely bug. So as for it makes sens to put checks in this routines with given above kind of hack to handle jiffies overflow. And add const for longest timer expires period - ((ULONG_MAX/2)-1)
For example I need timer at top for about 45 seconds. Not more.
TCP timers at most about 1.5/2 minutes long.

I have no clue what those stuff in internal_add_timer() does - so I cannot produce any patch to try. I can only guess what there really going on. But case of expires overflow is clearly stated there as case when ((signed long) idx < 0) - timer "in the past" comment. But whole ide of those queueing is pretty obscure. And no external reference for algoritms/alike...

--
Ihar 'Philips' Filipau / with best regards from Saarbruecken.
-- _ _ _
"... and for $64000 question, could you get yourself |_|*|_|
vaguely familiar with the notion of on-topic posting?" |_|_|*|
-- Al Viro @ LKML |*|*|*|

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/