[Top] [All Lists]

Re: [Fwd: Re: possible bug x86 2.4.2 SMP in IP receive stack]

To: Bob Felderman <feldy@xxxxxxxx>
Subject: Re: [Fwd: Re: possible bug x86 2.4.2 SMP in IP receive stack]
From: Donald Becker <becker@xxxxxxxxx>
Date: Tue, 6 Mar 2001 02:13:49 -0500 (EST)
Cc: andrewm@xxxxxxxxxx, kuznet@xxxxxxxxxxxxx, netdev@xxxxxxxxxxx
In-reply-to: <3AA42B7B.7C562799@xxxxxxxxxxxxxxxx>
Sender: owner-netdev@xxxxxxxxxxx
On Mon, 5 Mar 2001, Jeff Garzik wrote:

> > The driver does (and always has had)
> > 
> >     if (test_and_set_bit(0, (void *) &is->arch.interrupt) != 0) {
> That is most definitely -not- good SMP locking.  In normal drivers on
> normal hardware, the interrupt handler is never ever called twice
> anyway.  This code is an artifact of Donald Becker's driver skeleton,
> which includes this check.  A few of his drivers call the interrupt
> handler routine from normal driver code, thus requiring the check.  Most
> drivers do not need this check.

No, this check is to avoid a bug in the Linux interrupt dispatch code
that called an interrupt handler simultaneously.  It only occured on SMP
machines, but it was very bad.

I can see the response coming.. it usually sounds like "there is no such
bug, but it was fixed a long time ago".  Much like a regression test,
keeping the check in a few places assures us that the bug isn't recurring.

> Read Documentation/networking/netdevices.txt in 2.4.x kernels.  Also,
> since it doesn't cover interrupt handling and hardware, the basic rule
> is:
> * spin_lock around your Tx interrupt handling path.
> * spin_lock_irq around your dev->hard_start_xmit Tx submission code.

With some hardware designs you shouldn't need these locks.

Donald Becker                           becker@xxxxxxxxx
Scyld Computing Corporation   
410 Severn Ave. Suite 210               Second Generation Beowulf Clusters
Annapolis MD 21403                      410-990-9993

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