lkml.org 
[lkml]   [2003]   [Nov]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Q] jiffies overflow & timers.
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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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