[Top] [All Lists]

Re: tx_timeout and timer serialisation

To: Andrew Morton <andrewm@xxxxxxxxxx>
Subject: Re: tx_timeout and timer serialisation
From: Andrey Savochkin <saw@xxxxxxxxxxxxx>
Date: Mon, 22 May 2000 09:44:19 +0800
Cc: netdev@xxxxxxxxxxx
In-reply-to: <>; from "Andrew Morton" on Sat, May 20, 2000 at 09:27:18PM
References: <> <Pine.LNX.4.10.10005192039250.825-100000@vaio.greennet>, <Pine.LNX.4.10.10005192039250.825-100000@vaio.greennet>; <> <>, <>; <> <>
Sender: Majordomo List Manager <majordomo@xxxxxxxxxxx>

On Sat, May 20, 2000 at 09:27:18PM +1000, Andrew Morton wrote:
> Andrey Savochkin wrote:
> > 
> > We need to serialize the timer handler with outside code (which runs not in
> > BH or IRQ context).  For 2.2 del_timer call should be in bh_atomic section.
> hmm.. I'm not too familiar with that part of 2.2.  Could you please cook
> up a patch to show me what you mean, then I'll torture it a bit.

For eepro100 it should be

--- eepro100.c  Tue Apr  4 11:05:23 2000
+++ eepro100.c-timer    Mon May 22 09:35:52 2000
@@ -1799,7 +1799,9 @@
                           dev->name, inw(ioaddr + SCBStatus));
        /* Shut off the media monitoring timer. */
+       start_bh_atomic();
+       end_bh_atomic();
        /* Shutting down the chip nicely fails to disable flow control. So.. */
        outl(PortPartialReset, ioaddr + SCBPort);

> Does the BH synchronisation work within a BH or an IRQ?  What happens if


> we call del_timer within a BH or IRQ when the handler is currently
> running? 

As far as I remember, all BHs were single threaded in 2.2 kernels, so if
we're in BH, handler can't run on another CPU.
And start_bh_atomic may be safely called from BHs and IRQs.  It does nothing
special in this case.

Best regards

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