[Top] [All Lists]

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

To: Noah Romer <klevin@xxxxxxxxxx>
Subject: Re: [Fwd: Re: possible bug x86 2.4.2 SMP in IP receive stack]
From: Jes Sorensen <jes@xxxxxxxxxxxxx>
Date: 06 Mar 2001 17:43:38 +0100
Cc: Jeff Garzik <jgarzik@xxxxxxxxxxxxxxxx>, netdev@xxxxxxxxxxx
In-reply-to: Noah Romer's message of "Mon, 5 Mar 2001 18:19:30 -0800 (PST)"
References: <Pine.SUN.3.96.1010305181600.15630A-100000@xxxxxxxxxx>
Sender: owner-netdev@xxxxxxxxxxx
User-agent: Gnus/5.070096 (Pterodactyl Gnus v0.96) Emacs/20.4
>>>>> "Noah" == Noah Romer <klevin@xxxxxxxxxx> writes:

Noah> On Mon, 5 Mar 2001, Jeff Garzik wrote:
>> * 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.

Noah> Well, if the Rx code modifies anything that is shared by all
Noah> instances of the Rx code (i.e. a queue or stack), you're going
Noah> to need to lock around those access points in order to be SMP
Noah> safe. If the Rx code is in an interrupt context, then you've got
Noah> to spin_lock_irq.

You don't need to use spin_lock_irq() in an interrupt handler as you
are always guaranteed that the current interrupt handler is never
disturbed by anyone else.

Using spin_lock_irqsave() is preferred to spin_lock_irq() as
spin_lock_irq() is dodgy to implement on some architectures.


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