[Top] [All Lists]

Re: [PATCH] Tulip interrupt uses non IRQ safe spinlock

To: Mark Broadbent <markb@xxxxxxxxxxxxxx>
Subject: Re: [PATCH] Tulip interrupt uses non IRQ safe spinlock
From: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Date: Tue, 3 May 2005 19:07:57 +1000
Cc: vsu@xxxxxxxxxxx, davem@xxxxxxxxxxxxx, netdev@xxxxxxxxxxx
In-reply-to: <57556.>
References: <E1DRFqC-00028H-Qi@tigger> <E1DRGWv-0003aa-00@xxxxxxxxxxxxxxxxxxxxxxxx> <20050429093521.274adf9a.davem@xxxxxxxxxxxxx> <20050429214336.04b40b3f.vsu@xxxxxxxxxxx> <4276238E.4060606@xxxxxxxxxxxxxx> <20050502212819.GA16177@xxxxxxxxxxxxxxxxxxx> <57556.>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mutt/1.5.6+20040907i
On Tue, May 03, 2005 at 09:25:26AM +0100, Mark Broadbent wrote:
> >> See Documentation/spin-locking.txt line 137, this states that
> >> spin_[un]lock() should not be used in IRQ handlers.
> "If you have a case where you have to protect a data structure across
> several CPU's and you want to use spinlocks you can potentially use
> cheaper versions of the spinlocks. IFF you know that the spinlocks are
> never used in interrupt handlers, you can use the non-irq versions:
>       spin_lock(&lock);
>       ...
>       spin_unlock(&lock);
> "

Yes this isn't very clear.

What it's trying to say that if you're in a softirq/user context
and the spin lock may be taken in an IRQ context elsewhere then
you must use the IRQ-disabling version.

However, if you're in the IRQ context yourself, and yours is the
only IRQ context that takes that spin lock, then you may use the
straight spin_lock version.

Visit Openswan at
Email: Herbert Xu ~{PmV>HI~} <herbert@xxxxxxxxxxxxxxxxxxx>
Home Page:
PGP Key:

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