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
|