On 11/23/2016 2:17 AM, Bart Van Assche wrote:
Additionally, rename srp_wait_for_queuecommand() into
scsi_wait_for_queuecommand() and add a comment about the
queuecommand() call from scsi_send_eh_cmnd().
Note: this patch changes scsi_internal_device_block from a function
that did not sleep into a function that may sleep. This is fine for
all callers of this function:
* scsi_internal_device_block() is called from the mpt3sas device while
that driver holds the ioc->dm_cmds.mutex. This means that the mpt3sas
driver calls this function from thread context.
* scsi_target_block() is called by __iscsi_block_session() from
kernel thread context and with IRQs enabled.
* The SRP transport code also calls scsi_target_block() from kernel
thread context while sleeping is allowed.
* The snic driver also calls scsi_target_block() from a context from
which sleeping is allowed. The scsi_target_block() call namely occurs
immediately after a scsi_flush_work() call.
Signed-off-by: Bart Van Assche <bart.vanassche@xxxxxxxxxxx>
Reviewed-by: Sagi Grimberg <sagi@xxxxxxxxxxx>
Reviewed-by: Martin K. Petersen <martin.petersen@xxxxxxxxxx>
Cc: James Bottomley <jejb@xxxxxxxxxxxxxxxxxx>
Cc: Christoph Hellwig <hch@xxxxxx>
Cc: Doug Ledford <dledford@xxxxxxxxxx>
---
drivers/scsi/scsi_lib.c | 41 +++++++++++++++++++++++++++++++++++++--
drivers/scsi/scsi_transport_srp.c | 41 ++++++---------------------------------
2 files changed, 45 insertions(+), 37 deletions(-)
+
+/**
+ * scsi_wait_for_queuecommand() - wait for ongoing queuecommand() calls
+ * @shost: SCSI host pointer.
the arg is sdev.
+ *
+ * Wait until the ongoing shost->hostt->queuecommand() calls that are
+ * invoked from scsi_request_fn() have finished.
+ */
+static void scsi_wait_for_queuecommand(struct scsi_device *sdev)
+{
+ WARN_ON_ONCE(sdev->host->use_blk_mq);
+
+ while (scsi_request_fn_active(sdev))
+ msleep(20);
+}
+
+/**
* scsi_device_quiesce - Block user issued commands.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
