On Tue, 29 Feb 2000, Kurt Garloff wrote:
> On Sun, Feb 27, 2000 at 05:55:27PM -0800, Matthew Dharm wrote:
> > 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?
>
> And the code being called in the IRQ handler may be yours! It might
> IRQ from your SCSI controller ...
It can't be mine. I don't have an interrupt handler. I don't even have
an interrupt. This is a virtual HBA for USB Mass Storage devics.
> > > 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.
>
> Hmm? You should. Unless you have designed your IRQ handler to be very very
> carefully only doing atomic operations on data that you might access
> from your other code (i.e. queue_command()).
I don't have an irq handler, thus it doesn't access any data.
> Anyway, before calling scsi_done() on command completion, which you probably
> do from your IRQ handler, you have to acquire the io_request_lock.
Oh! This is new! I call the scsi_done() function from a thread that I've
started to handle these devices. But wait... I had a problem before
whereby I discovered that, in the process of calling scsi_done(), the
higher SCSI layers were acquiring the io_request_lock for me. If I
acquire the lock myself, won't this lead to deadlock?
> > The only thing I'm worried about is:
> >
> > IRQ -> irq handler -> queuecommand()
>
> Even if your IRQ handler does not do it, it might happen that another SCSI
> command on another Controller completes and that its IRQ handler calls
> scsi_done() and queue_command() is called to queue the next command to
> your controller. [Maybe the mid-layer avoid this, I don't know, but I
> certainly did not want to rely on it for saving 10 CPU cycles on a
> spinlock in a function that consumes 200+ anyway ...]
Hrm... this might be a legitimate problem. Can someone more knowledgable
with the mid-layer comment on the possibility of this scenario?
> > If that can't happen, then I'm free and clear to use the non IRQ-safe
> > spinlocks.
>
> If your SCSI controller uses an IRQ handler, I see no way to avoid
> IRQ safe spinlocks. Also think of SMP machines ...
What about SMP machines? I don't see a problem there with non-IRQ-safe
spinlocks, unless it's allready a problem on UP machines.
Matt Dharm
--
Matthew Dharm Home: [EMAIL PROTECTED]
Engineer, Qualcomm, Inc. Work: [EMAIL PROTECTED]
S: Another stupid question?
G: There's no such thing as a stupid question, only stupid people.
-- Stef and Greg
User Friendly, 7/15/1998
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
