Re: [PATCH] QStor SATA/RAID driver for 2.6.9-rc3

[Mark Lord]

Jeff Garzik wrote:
> > Yes.  The workqueue thread will invoke the mid-layer function,
> > which will do a queuecommand, which will return to the mid-layer,
> > which will then SLEEP waiting for the command to complete,
> > which will sleep that workqueue thread.
> >
> > As part of the interrupt processing to complete the command in the LLD,
> > it is possible that schedule_work may be necessary, requiring that
> > a workqueue thread be run.  If this means the same thread that is
> > already sleeping courtesy of the mid-layer, then we could have a problem.
>
> The only schedule_work() call in the SCSI common code is for domain
> validation.

This particulare schedule_work() would be invoked from
the interrupt handler in the LLD -- part of the qstor driver.

Is there a single thread (per CPU) for doing work from schedule_work(),
or are there multiple such threads created on demand?

If there's just a single thread, then this scenario (described above)
could indeed deadlock, in which case qstor cannot use schedule_work()
to perform notification of drive hot insert/removal events.

What do you think, Jeff?
--
Mark Lord
(hdparm keeper & the original "Linux IDE Guy")
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/