Re: [PATCH 06/21] qla2xxx: Simplify interrupt handler locking.

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Thu, 2008-04-03 at 15:07 -0700, Andrew Vasquez wrote:
> On Thu, 03 Apr 2008, James Bottomley wrote:
> 
> > On Thu, 2008-04-03 at 13:13 -0700, Andrew Vasquez wrote:
> > > There's no need to use the heavier (albiet safer)
> > > *_irq[save|restore]() locking primitives within the driver's
> > > interrupt handlers, interrupts are guaranteed to be
> > > non-reentrant.  Use lightweight spin_lock() and spin_unlock()
> > > primitives while acquiring the hardware_lock.
> > 
> > The above statement isn't entirely true: interrupts are not guaranteed
> > to be non re-entrant.  They are guaranteed not to be re-entered from the
> > *same* interrupt, but if you've got more than one card, the interrupt
> > routine can be executing simultaneously on an SMP system which is in
> > contravention of the classical definition of re-entrancy.
> >
> > So, the rules for locks in interrupt is that as long as the lock is
> > unique per interrupting instance (which it looks like yours are)
> 
> They are...

Thanks.

> > you can
> > get away with not requiring interrupt disables within critical sections
> > but if you have a more global lock which could be taken by different
> > interrupting entities then you must do interrupt disables still.
> 
> Thanks for the clarification.  Would you like me to resubmit with an
> altered changelog or can the current one glide in?

No .. that's OK ... I can't think of a better way to word it that won't
take up whole sentences.

James