netdev
[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: Jeff Garzik <jgarzik@xxxxxxxxxxxxxxxx>
Date: Mon, 05 Mar 2001 19:12:43 -0500
Cc: andrewm@xxxxxxxxxx, kuznet@xxxxxxxxxxxxx, netdev@xxxxxxxxxxx
Organization: MandrakeSoft
References: <200103060000.QAA21285@xxxxxxxxxxxxxxxx>
Sender: owner-netdev@xxxxxxxxxxx
Bob Felderman wrote:
> 
> => From andrewm@xxxxxxxxxx Mon Mar  5 15:50:15 2001
> => Your driver doesn't appear to have any SMP locking.  The
> => same skb can be fed to the network stack twice.
> 
> The driver does (and always has had)
> 
>     if (test_and_set_bit(0, (void *) &is->arch.interrupt) != 0) {
>                 /* hmm, interrupt called twice */
>                 [other stuff deleted]
>         }

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.

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.

Ideally your Rx interrupt handling path is independent of other code,
and need not be locked.

        Jeff


-- 
Jeff Garzik       | "You see, in this world there's two kinds of
Building 1024     |  people, my friend: Those with loaded guns
MandrakeSoft      |  and those who dig. You dig."  --Blondie

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