On 1/19/19 2:03 AM, Christoph Hellwig wrote:
On Wed, Jan 16, 2019 at 04:27:16PM -0800, Bart Van Assche wrote:
In scsi-mq mode it is not allowed to sleep inside srp_queuecommand() since the flag BLK_MQ_F_BLOCKING has not been set. Since setting the request queue flag BLK_MQ_F_BLOCKING would slow down the hot path, make srp_queuecommand() skip the mutex_lock() and mutex_unlock() calls when called from inside scsi_queue_rq() from the SCSI EH thread.
This patch avoids that the following appears in the kernel log:
I think we need to get rid of the taking a sleeping lock in ->queuecomand entirely. These checks are way to fragile.
Hi Christoph,
My own opinion is that the SCSI core should allow SCSI drivers to block all .queuecommand() calls e.g. to allow SCSI LLDs to perform error recovery. That is possible today for .queuecommand() calls that are the result of queueing a new command but not for .queuecommand() calls from the SCSI error handler. About three years ago I came up with multiple proposals for realizing such a change in the SCSI error handler. No matter what approach I proposed, the SCSI maintainer did not agree. No alternative approach was proposed either by the SCSI maintainer. That is why the srp_queuecommand() context check has been added to the SRP driver - there was no alternative.
How about proceeding with this patch and bringing up the SCSI error handler issue during LSF/MM? I hope that meeting in person will make it easier to reach agreement compared to an e-mail discussion. After an agreement has been reached and the SCSI error handler has been improved it will be possible to remove the context check from the SRP initiator driver.
Thanks,
Bart.