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.
Best regards
Andrey
|