Several SCSI low-level drivers need to suspend .queuecommand() calls while HBA or transport layer recovery happens. The iSCSI and SRP initiator drivers use scsi+AF8-target+AF8-block() to block new .queuecommand() calls while recovery happens. scsi+AF8-target+AF8-block() prevents that the block layer core triggers new .queuecommand() calls but does not prevent that the SCSI error handler calls .queuecommand(). SCSI LLD authors have the choice of either hoping that .queuecommand() calls from the SCSI error handler won't happen while transport layer recovery is in progress or to add code in the .queuecommand() function that detects from which context that call comes and to delay such .queuecommand() calls. In the SRP initiator driver that code looks as follows: const bool in+AF8-scsi+AF8-eh +AD0 +ACE-in+AF8-interrupt() +ACYAJg current +AD0APQ shost-+AD4-ehandler+ADs /+ACo +ACo The SCSI EH thread is the only context from which srp+AF8-queuecommand() +ACo can get invoked for blocked devices (SDEV+AF8-BLOCK / +ACo SDEV+AF8-CREATED+AF8-BLOCK). Avoid racing with srp+AF8-reconnect+AF8-rport() by +ACo locking the rport mutex if invoked from inside the SCSI EH. +ACo-/ if (in+AF8-scsi+AF8-eh) mutex+AF8-lock(+ACY-rport-+AD4-mutex)+ADs In my opinion the SCSI core should make it easy for LLD authors to prevent that the error handler calls .queuecommand() while transport layer recovery is in progress. So considerable time ago I posted several patches that modify the SCSI error handler and that avoid that SCSI LLDs have to detect the context a .queuecommand() call comes from. None of these patches were accepted and no alternative approach was proposed. Hence the proposal to discuss this topic in person during LSF/MM. See also +ACIAWw-PATCH 1/2+AF0 RDMA/srp: Avoid calling mutex+AF8-lock() from inside scsi+AF8-queue+AF8-rq()+ACI (https://www.spinics.net/lists/linux-rdma/msg73842.html). Thanks, Bart.
