> > This is true for the old exception handling. I think it was one of the
> > objectives to remove this behaviour in the new EH code, but I'm not sure
> > it's always accomplished. Eric Youngdale should be able to comment on
that.
> >
> > Anyway, I think you need to use the irq safe spinlock anyway, cause
> > otherwise you risk:
> >
> > queue_command(): spinlock
> > IRQ -> irq handler: spinlock_irqsave() will deadlock!!
>
> But I don't have an IRQ handler that will try to obtain the lock. The
> only thing I'm worried about is:
>
> IRQ -> irq handler -> queuecommand()
>
> If that can't happen, then I'm free and clear to use the non IRQ-safe
> spinlocks.
When you are using the new error handling code, the post-processing of
commands is done from a bottom-half handler. Thus your interrupt handler
will have returned by the time that a queuecommand is called again. Keep
in mind that on an SMP machine you could have an interrupt being handled on
one processor and a new command being queued on a second processor - this is
why we tend to always use the IRQ safe spinlocks throughout SCSI.
Also, the bottom half handlers are run while the processor is
interrupted. By this I mean that some other task was still pre-empted when
the handler runs. The thing you gain is that you can guarantee that your
low-level handler has returned before the queuecommand function is called
again.
-Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
