----- Original Message -----
From: "Matthew Dharm" <[EMAIL PROTECTED]>
To: "Kurt Garloff" <[EMAIL PROTECTED]>
Cc: "The Linux SCSI list" <[EMAIL PROTECTED]>
Sent: Tuesday, February 29, 2000 4:32 PM
Subject: Re: queueing commands and IRQs?
> 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.
What context is command completion run from then? Some sort of USB
interrupt handler, or a worker thread of some type?
> > > > 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?
No. scsi_done() is *assuming* that the lock is held when it is called,
at least for now. Actually if you are using the new error handling it
doesn't really matter, as all we are doing is sticking it in a list for the
bottom half handler, and there is a separate lock to protect that operation
(for the day when we fix SMP locking once and for all).
> > > 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?
With the new queueing code, I believe that this will no longer happen.
With the old queueing code I could guarantee that it would happen.
> > > 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.
What it boils down to is whether there is ever any work that is done in
the context of any interrupt handler or not. If not (i.e. you are using
worker threads for reporting completion), then it is probably true that
using the non-IRQ-safe versions would work even on an SMP machine.
-Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
