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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html