netdev
[Top] [All Lists]

Re: tx_timeout and timer serialisation

To: Andrey Savochkin <saw@xxxxxxxxxxxxx>
Subject: Re: tx_timeout and timer serialisation
From: Andrew Morton <andrewm@xxxxxxxxxx>
Date: Sat, 20 May 2000 16:24:08 +1000
Cc: "David S. Miller" <davem@xxxxxxxxxx>, becker@xxxxxxxxx, netdev@xxxxxxxxxxx, jgarzik@xxxxxxxxxxxxxxxx
References: <3925BB00.B1CDDFE7@mandrakesoft.com> <Pine.LNX.4.10.10005192039250.825-100000@vaio.greennet>, <Pine.LNX.4.10.10005192039250.825-100000@vaio.greennet>; <20000520122715.A7682@saw.sw.com.sg> <39262113.19447850@uow.edu.au> <200005200524.WAA18905@pizda.ninka.net>, <200005200524.WAA18905@pizda.ninka.net>; from "David S. Miller" on Fri, May 19, 2000 at 10:24:39PM <20000520133807.B8149@saw.sw.com.sg>
Sender: owner-netdev@xxxxxxxxxxx
Andrey Savochkin wrote:
> 
> On Fri, May 19, 2000 at 10:24:39PM -0700, David S. Miller wrote:
> >    Date: Sat, 20 May 2000 15:22:27 +1000
> >    From: Andrew Morton <andrewm@xxxxxxxxxx>
> >
> >    I have just written a little kernel module which has confirmed that the
> >    handler-keeps-running-after-del_timer bug exists in both 2.2.14 and
> >    2.3.99-pre9.  Not good.  Very not good, IMO.
> >
> > I just noticed this thread, and has del_timer_sync been mentioned yet?
> > That is what should be used to make sure the timer is done in 2.3.x,
> > unless something else prevents it's usage (locking conflict).
> 
> del_timer_sync doesn't ensure that the timer has really exited (as opposite
> to just calling timer_exit()).
> We cannot free the code segment where the timer handler resides even
> with del_timer_sync!

yes, there's that.  Plus del_timer_sync() is a bit racy anyway.  Quoting
myself:

int del_timer_sync(struct timer_list * timer)
{
        int ret = 0;

        for (;;) {
                unsigned long flags;
                int running;

                spin_lock_irqsave(&timerlist_lock, flags);

** The timer handler could be running now.  It can delete the
   timer and kfree it, or reuse its memory for something else,
   or turn it into a semantically different timer **

                ret += detach_timer(timer);
                timer->list.next = timer->list.prev = 0;
** uh-oh **


Plus it requires exit_timer(), plus it doesn't exist in 2.2 :(




Regarding this:

   ( I wanna know why my kernel thread shows up in ps as "insmod
   timertest.o" but everyone else's has nifty names like "[kflushd]" )

sprintf(current->comm, "nifty name");

Yes, I did that.  My niftyname is "timertest".  And indeed, 'killall
timertest' works, but 'ps' still shows it as 'insmod timertest.o'.  2.2
as well as 2.3.  Not a very high priority item.


-- 
-akpm-

<Prev in Thread] Current Thread [Next in Thread>