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

[Jeff Garzik]

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


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