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

[James Bottomley <James.Bottomley@SteelEye.com>]

On Tue, 2004-10-12 at 12:22, Mark Lord wrote:
> 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.
> 
> Again, the scenario is:  schedule_work is used to have a work function
> invoked asynchronously, which then invokes scsi_add_device(),
> which then queues a command to the device and SLEEPS awaiting
> completion of the (INQUIRY) command.
> 
> 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.

In that scenario, you use a separate workqueue.

However, when I last looked at your driver you were only using the
thread to provide user context for hotplug events ... where did this
back end finishing thread come from?

James