Hello,
On Tue, May 02, 2000 at 07:49:00PM +0400, A.N.Kuznetsov wrote:
> > But eepro100 uses del_timer_sync() in tx_timeout() (not under any
> > spinlock)
>
> Do not forget, it is under dev->xmit_lock!
>
> If media timer will grab it too -> deadlock.
Calling del_timer_sync() may look dangerous, but media timer doesn't grab any
locks (and I will keep it this way in the future).
[snip]
> Essentially, it is replacement for combination:
>
> del_timer();
> synchronize_bh();
>
> used in 2.2. I.e. delete and wait for all pending BHs to complete.
That's it.
I made a mistake by not calling timer_exit(), I'll fix it.
>
> del_timer_sync() deletes and waits only for _this_ timer to complete.
> It can be used from any context, provided user is sure that there
> are no deadlocks.
>
> Alas, it has fatal bug. Namely, timer handler _code_ can be released
> in between timer_exit() and return from handler. It is utterly
> unlikely, but the bug is fatal. 8) I do not know how to repair
> this without refcounts.
I don't see a big problem here.
We do not want to wait for the end of the handler.
We want to synchronise against some operations inside the handler.
If timer_exit() is called after the end of the operations, or goal is
reached. The another important point is that the handler must not be called
again in the same timer BH, but that's true.
Best regards
Andrey V.
Savochkin
|