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

[Mark Lord <lkml@rtr.ca>]

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")