Doru Petrescu wrote:
>
> also I don't understand how a race condition can occour since all
> functions that play with the lists has a spin_lock() arround them.
> Maybe is not someting wrong in the timers, maybe some other part of the
> kernel is doing the bad thing.
Yes. All it takes is this:
handler(foo)
{
stuff();
mod_timer(&foo->timer, whenever);
}
mainline()
{
del_timer(&foo->timer);
kfree(foo);
}
If the handler and mainline run at the same time
we will add a timer which is in freed memory. Later,
someone reuses that memory and changes it. The timer
list is corrupted.
Problem is, it seems that your machine is using
IPV4, TCP, IDE, netfilter and nothing else. Those
parts of the kernel don't have the above bug (well,
they didn't mid last year).
One really, really useful piece of information would
be the value of the `function' member of the corrupted
timer. Your debug code prints this out. Do you still
have the logs?
Was it ever non-zero?
If so, what function was it pointing at?
-
> Problem is, it seems that your machine is using
> IPV4, TCP, IDE, netfilter and nothing else. Those
> parts of the kernel don't have the above bug (well,
> they didn't mid last year).
>
> One really, really useful piece of information would
> be the value of the `function' member of the corrupted
> timer. Your debug code prints this out. Do you still
> have the logs?
>
> Was it ever non-zero?
>
> If so, what function was it pointing at?
The matchine crashed several times, BEFORE I modified timer.c
it did NOT CRASHED even once after that :(
I am waiting for it to chrash.
when it will crash, I will let you guys know.
But, as I stated before, I fear that because of the changes, the race
condition does not happen any more ...
Best regards,
------
Doru Petrescu
KappaNet - Senior Software Engineer
E-mail: [email protected] LINUX - the choice of the GNU generation