help with linux kernel timers

Giacomo delleceste at gmail.com
Sat Oct 29 20:12:17 CEST 2005


Good morning, in my kernel code, which handles timeouts for connection
tables in a linked list, i do:

inline void update_timer_of_state_entry(struct state_table *sttable)
{
 if (sttable->state.state == ESTABLISHED)
  mod_timer(&sttable->timer_statelist,
     jiffies + HZ * state_lifetime);
 else
  mod_timer(&sttable->timer_statelist,
     jiffies + HZ * setup_shutd_state_lifetime);
}

sttable is a structure which contains a struct timer_list.

In:

mod_timer(&sttable->timer_statelist,
     jiffies + HZ * state_lifetime);

i update the timeout for the structures, so that when timer expires,
structure is removed from linked list.

The problem is that when state lifetime is long, let's say 2592000 for
instance, kernel goes in panic!

If the value is low, say 300, or higher 259200000, ok!

I suspect a problem of overflow .. is it possible?

What can be wrong?

Thanks a lot for any hint!

OTHER THINGS:

My data structures are accessed in atomic context, since they contain data
regarding internet packets. When timer expires, the function handler simply
removes the structure from the linked list, i suppose when out of the atomic
context.

This happens:

1. a packet is received from the network;
2. If packet is allowed to pass through the filter, a data structure is
allocated
and contains the data related to the socket.
3. A timer is initialized, and updated every time a new packet matches the
data stored in the structure.
4. When no more packets of that kind are received, timer expires and table
is deleted from linked list.

But, in my scenario, 4 in theory does not happen since timeout is very long,
as i said in my first mail.

Things worked ok for months, until i changed timeout to some million of
seconds... (example 2592000)..
but if i increase it again (25920000) things go well again.. this makes me
think of some
overflow...

Structures affected are only accessed in kernel space in softirq context
(network reception).

Thanks a lot!

Giacomo.



Giacomo.



More information about the netfilter-devel mailing list