On Mon, 28 Feb 2000, Kurt Garloff wrote:

> 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.

Maybe I'm missing something, but if I get an interrupt while I'm working
on a command, then doesn't the interrupt handler get invoked?  That is, my
code stops executing while the interrupt is being serviced.  My code,
which then calls scsi_done(), doesn't start executing until after the
interrupt is serviced and I've returned to my context?

> 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.

Matt Dharm

-- 
Matthew Dharm                              Home: [EMAIL PROTECTED] 
Engineer, Qualcomm, Inc.                         Work: [EMAIL PROTECTED]

I want my GPFs!!!
                                        -- Stef
User Friendly, 11/9/1998


-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]

Reply via email to