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

[Jeff Garzik <jgarzik@pobox.com>]

On Tue, Oct 12, 2004 at 12:59:01PM -0400, Mark Lord wrote:
> James Bottomley wrote:
> >On Fri, 2004-10-08 at 10:38, Mark Lord wrote:
> >
> >>Can deadlock occur here, since qstor.c is already using schedule_work()
> >>as part of it's internal bottom-half handling for abnormal conditions?
> >>
> >>Eg.  hotplug event -> schedule_work -> mid-layer -> queuecommand
> >>      --> sleep  :: interrupt -> schedule_work -> deadlock?
> >>
> >
> >
> >Since you wouldn't go straight from schedule_work->mid-layer, I assume
> >you mean that when the workqueue thread runs the work?
> 
> 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.

All the other stuff is done by the totally independent error handling
threads, or by non-process contexts such as tasklets.

	Jeff