netdev
[Top] [All Lists]

Re: tx_timeout and timer serialisation

To: Andrey Savochkin <saw@xxxxxxxxxxxxx>
Subject: Re: tx_timeout and timer serialisation
From: Donald Becker <becker@xxxxxxxxx>
Date: Sat, 20 May 2000 03:11:14 -0400 (EDT)
Cc: netdev@xxxxxxxxxxx
In-reply-to: <20000520122715.A7682@xxxxxxxxxxxxx>
Sender: owner-netdev@xxxxxxxxxxx
On Sat, 20 May 2000, Andrey Savochkin wrote:
> On Fri, May 19, 2000 at 08:48:15PM -0400, Donald Becker wrote:
> > On Fri, 19 May 2000, Jeff Garzik wrote:
> > 
> > > > I don't see the semantic problem here.
> > > > This was the recommended way to use the timer routines.  If the 
> > > > semantics
> > > > have changed, there should be new names for the changed semantics.
> > > 
> > > There doesn't seem to be anything in 2.2.x to prevent this sort of race
> > > at del_timer time.  It always seemed to me like a driver-specific wait
> > > queue was needed for certain points in the close() process, like this.
> > 
> > There is no "wait queue" that can cover broken semantics.
> > 
> > The expected semantics must be "remove this timer from the kernel timer
> > control".
> > After calling del_timer(&timer),
> >   - kfree(timer.data) is safe
> >   - a module with the timer.function() code may be immediately removed.
> > 
> > It's possible for each driver to add locks so that #1 is true, but there is
> > no work-around if #2 does not hold true.  The timer function might have
> > released its lock, but still be exiting.
> 
> #2 is not true.
> I suppose, del_timer() call should be wrapped by
> start_bh_atomic/end_bh_atomic pair which provides global serialization
> against BHs.

I stand corrected -- this does appear to be a valid work-around in 2.2+SMP to
avoid the timer handler running when we call del_timer().  But you will
agree that it's a ugly hack that shouldn't need to be done by driver code.
It's also potentially inefficient -- del_timer() doesn't need to protect
against arbitrary BHes, only against the timer BH or just our specific timer.

I had been assuming that the 2.2+SMP the behavior was the del_timer() was
always safe in netdevice->stop(), since netdevice->stop() was protected by the
"big kernel lock".

Donald Becker                           becker@xxxxxxxxx
Scyld Computing Corporation
410 Severn Ave. Suite 210
Annapolis MD 21403



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