On Fri, Feb 25, 2000 at 03:22:00PM -0800, Matthew Dharm wrote:
> I think I know the answer to this, but if I'm wrong all sorts of bad will
> happen, so I figured I'd bother the experts to make sure. :)
>
> When the SCSI layers calls a host's command queue function, is there any
> possibility that the context will be interrupt context? Basically, I need
> to know if I need spin_lock() or spin_lock_irqsave(). The non-irq safe
> version is "much faster" (according to Linus in spinlock.txt).
There is a possibility that you are in IRQ context: You get a couple of
interrupts when the command is being processed by the device and on
completion, you call scsi_done (). The mid-layer may immediately call
queue_command() again to queue the nect cmnd.
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!!
That's the normal scenario, at least if you just use one adapter specific
lock or the global io_request_lock.
BTW: The io_request_lock is being locked from mid-layer, except (obviously)
for the IRQ handler.
Hope this helps.
--
Kurt Garloff <[EMAIL PROTECTED]> Eindhoven, NL
GPG key: See mail header, key servers Linux kernel development
SuSE GmbH, Nuernberg, FRG SCSI, Security
PGP signature
