This looks ok.
Apart from this, I tested linux-next (without this patch) - which
includes Ming's changes to replace sdev-->device_busy with sbitmap -
and, as expected, it has the issue.
So I think it is also worth having this to stop this happening elsewhere:
------>8-------
Subject: [PATCH] scsi: core: Cap initial sdev queue depth at Shost.can_queue
Function sdev_store_queue_depth() enforces that the sdev queue depth
cannot exceed Shost.can_queue.
However, the LLDD may still set cmd_per_lun > can_queue, which would
lead to an initial sdev queue depth greater than can_queue.
Stop this happened by capping initial sdev queue depth at can_queue.
<insert credits>
Signed-off-by: John Garry <john.garry@xxxxxxxxxx>
diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
index 9af50e6f94c4..fec6c17ff37c 100644
--- a/drivers/scsi/scsi_scan.c
+++ b/drivers/scsi/scsi_scan.c
@@ -218,6 +218,7 @@ static struct scsi_device *scsi_alloc_sdev(struct
scsi_target *starget,
struct scsi_device *sdev;
int display_failure_msg = 1, ret;
struct Scsi_Host *shost = dev_to_shost(starget->dev.parent);
+ int depth;
sdev = kzalloc(sizeof(*sdev) + shost->transportt->device_size,
GFP_KERNEL);
@@ -276,8 +277,13 @@ static struct scsi_device *scsi_alloc_sdev(struct
scsi_target *starget,
WARN_ON_ONCE(!blk_get_queue(sdev->request_queue));
sdev->request_queue->queuedata = sdev;
- scsi_change_queue_depth(sdev, sdev->host->cmd_per_lun ?
- sdev->host->cmd_per_lun : 1);
+ if (sdev->host->cmd_per_lun)
+ depth = min_t(int, sdev->host->cmd_per_lun,
+ sdev->host->can_queue);
+ else
+ depth = 1;
+
+ scsi_change_queue_depth(sdev, depth);
scsi_sysfs_device_initialize(sdev);
