On 09/12/12 22:53, Tejun Heo wrote:
> The problem at hand IIUC is ->request_fn() being invoked when
> request_queue itself is alive but the underlying driver is gone.  We
> already make sure that a new request is not queued once drain is
> complete but there's no guarantee about calling into ->request_fn()
> and this is what you want to fix, right?

Actually it's a slightly different issue that I want to address, namely
that with the current implementation of the block layer and the SCSI
core it's possible that blk_cleanup_queue() finishes after
scsi_request_fn() has unlocked the queue lock and before it obtains the
queue lock again.

The reason I'm proposing to add a counter in the block layer and not in
the SCSI core is because I think it would be useful for other
request-based block drivers too to be able to unlock the queue inside
their ->request_fn(). That would allow to reduce lock contention on the
request_queue lock for low-latency block drivers.

Bart.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to