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

[Mark Lord]

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.

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.

Right?
--
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/