[Top] [All Lists]

Re: tx_timeout and timer serialisation

To: kuznet@xxxxxxxxxxxxx, Andrew Morton <andrewm@xxxxxxxxxx>
Subject: Re: tx_timeout and timer serialisation
From: Andrey Savochkin <saw@xxxxxxxxxxxxx>
Date: Wed, 3 May 2000 10:39:22 +0800
Cc: netdev@xxxxxxxxxxx
In-reply-to: <200005021549.TAA16319@xxxxxxxxxxxxx>; from "A.N.Kuznetsov" on Tue, May 02, 2000 at 07:49:00PM
References: <390EE5BB.2AF2F1CD@xxxxxxxxxx> <200005021549.TAA16319@xxxxxxxxxxxxx>
Sender: owner-netdev@xxxxxxxxxxx

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).

> 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.

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