This depends where you use it. cli/sti is now really a deep magic back
compatibility tweak. To quote the code
* A global "cli()" while in an interrupt context
* turns into just a local cli(). Interrupts
* should use spinlocks for the (very unlikely)
* case that they ever want to protect against
* each other.
*
* If we already have local interrupts disabled,
* this will not turn a local disable into a
* global one (problems with spinlocks: this makes
* save_flags+cli+sti usable inside a spinlock).
> I thought about replacing the cli() by spin_lock_irqsave(&hwgroup->spinlock)
> it the request-generator part of the driver but I'm not sure if this is
> enough yet, since the interrupt handler is called without the spinlock,
> and we might have to acquire it there as well.
That is why you need spin_lock_irqsave. The local cpu goes to cli() state
the other CPU's will spin if needed. In the irq handler just use
spin_lock(). Since the IRQ handler can only get into this state on
another CPU it is safe. And since the code in the other context has a bounded
completion time and is irq disabled you know it will complete allowing
the system to move on.
The spin_lock stuff is way more efficient SMP than a straight cli/sti. On
uniprocessor it basically comes out the same.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/