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

[Jeff Garzik <jgarzik@pobox.com>]

Mark Lord wrote:
> James Bottomley wrote:
>  >
> 
>> So, it's perfectly legal to call schedule_work from within the work
>> queue function, because all you do is add the work to the list for the
>> daemon thread to execute when it gets to it.  There's nothing
>> synchronous about a workqueue.  If a work function sleeps, then its
>> true, it takes the worker thread longer to get to the next work item,
>> but as long as the work function awakes, it will get there.
> 
> 
> Good.  That is exactly how I suspected it worked.
> In which case, deadlock *will* happen in the scenario described,
> and the qstor driver should therefore NOT use schedule_work()
> as the means of invoking the scsi_add_device()/scsi_remove_device()
> functions.  A separate thread appears needed.

Did you read my message???

QStor doesn't do domain validation, which is the only place where the 
SCSI core also calls schedule_work().

Your conclusion is incorrect AFAICS.


> As part of handling the command in the LLD, the qstor_intr() handler
> may use a (schedule_work) function to perform bottom-half processing
> for that very same command.  If the worker thread is stuck sleeping
> in the mid-layer, then it will never get around to the qstor bottom-half
> processing that is needed to complete the original activity.
> 
> Dead-lock.
> 
> Right?

If you are creating a deadlock within your own driver, that's a separate 
issue.  There is no deadlock with the SCSI core.

However...  tasklets are for bottom-half processing, not threads.

	Jeff