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

[Jeff Garzik]

On Tue, Oct 12, 2004 at 01:14:01PM -0400, Mark Lord wrote:
> Jeff Garzik wrote:
> >
> >>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.
> 
> This particulare schedule_work() would be invoked from
> the interrupt handler in the LLD -- part of the qstor driver.
> 
> Is there a single thread (per CPU) for doing work from schedule_work(),
> or are there multiple such threads created on demand?
> 
> If there's just a single thread, then this scenario (described above)
> could indeed deadlock, in which case qstor cannot use schedule_work()
> to perform notification of drive hot insert/removal events.
> 
> What do you think, Jeff?

Your assessment is correct, in that, on single-CPU systems there is only
one thread for schedule_work() events.  For each workqueue, there is one
thread per CPU.

That does not preclude (a) using a private workqueue, rather than the
general one or (b) using the kthread API as Christoph suggested.

	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/