On Sep 8, 2020, at 3:22 PM, Paolo Bonzini pbonzini@redhat.com wrote:
On 28/08/20 14:21, Matej Genci wrote:
VirtIO 1.0 spec says The removed and rescan events ... when sent for LUN 0, they MAY apply to the entire target so the driver can ask the initiator to rescan the target to detect this.
This change introduces the behaviour described above by scanning the entire scsi target when LUN is set to 0. This is both a functional and a performance fix. It aligns the driver with the spec and allows control planes to hotplug targets with large numbers of LUNs without having to request a RESCAN for each one of them.
Signed-off-by: Matej Genci matej@nutanix.com Suggested-by: Felipe Franciosi felipe@nutanix.com
drivers/scsi/virtio_scsi.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c index bfec84aacd90..a4b9bc7b4b4a 100644 --- a/drivers/scsi/virtio_scsi.c +++ b/drivers/scsi/virtio_scsi.c @@ -284,7 +284,12 @@ static void virtscsi_handle_transport_reset(struct virtio_scsi *vscsi,
switch (virtio32_to_cpu(vscsi->vdev, event->reason)) { case VIRTIO_SCSI_EVT_RESET_RESCAN:
scsi_add_device(shost, 0, target, lun);
if (lun == 0) {
scsi_scan_target(&shost->shost_gendev, 0, target,
SCAN_WILD_CARD, SCSI_SCAN_INITIAL);
} else {
scsi_add_device(shost, 0, target, lun);
break; case VIRTIO_SCSI_EVT_RESET_REMOVED: sdev = scsi_device_lookup(shost, 0, target, lun);}
Acked-by: Paolo Bonzini pbonzini@redhat.com
Cc: stable@vger.kernel.org
Thanks, Paolo.
I'm Cc'ing stable as I believe this fixes a driver bug where it doesn't follow the spec. Per commit message, today devices are required to issue RESCAN events for each LUN behind a target when hotplugging, or risking the driver not seeing the new LUNs.
Is this enough? Or should we resend after merge per below? https://www.kernel.org/doc/Documentation/process/stable-kernel-rules.rst
F.
On Tue, Sep 08, 2020 at 05:53:16PM +0000, Felipe Franciosi wrote:
On Sep 8, 2020, at 3:22 PM, Paolo Bonzini pbonzini@redhat.com wrote:
On 28/08/20 14:21, Matej Genci wrote:
VirtIO 1.0 spec says The removed and rescan events ... when sent for LUN 0, they MAY apply to the entire target so the driver can ask the initiator to rescan the target to detect this.
This change introduces the behaviour described above by scanning the entire scsi target when LUN is set to 0. This is both a functional and a performance fix. It aligns the driver with the spec and allows control planes to hotplug targets with large numbers of LUNs without having to request a RESCAN for each one of them.
Signed-off-by: Matej Genci matej@nutanix.com Suggested-by: Felipe Franciosi felipe@nutanix.com
drivers/scsi/virtio_scsi.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c index bfec84aacd90..a4b9bc7b4b4a 100644 --- a/drivers/scsi/virtio_scsi.c +++ b/drivers/scsi/virtio_scsi.c @@ -284,7 +284,12 @@ static void virtscsi_handle_transport_reset(struct virtio_scsi *vscsi,
switch (virtio32_to_cpu(vscsi->vdev, event->reason)) { case VIRTIO_SCSI_EVT_RESET_RESCAN:
scsi_add_device(shost, 0, target, lun);
if (lun == 0) {
scsi_scan_target(&shost->shost_gendev, 0, target,
SCAN_WILD_CARD, SCSI_SCAN_INITIAL);
} else {
scsi_add_device(shost, 0, target, lun);
break; case VIRTIO_SCSI_EVT_RESET_REMOVED: sdev = scsi_device_lookup(shost, 0, target, lun);}
Acked-by: Paolo Bonzini pbonzini@redhat.com
Cc: stable@vger.kernel.org
Thanks, Paolo.
I'm Cc'ing stable as I believe this fixes a driver bug where it doesn't follow the spec. Per commit message, today devices are required to issue RESCAN events for each LUN behind a target when hotplugging, or risking the driver not seeing the new LUNs.
Is this enough? Or should we resend after merge per below? https://www.kernel.org/doc/Documentation/process/stable-kernel-rules.rst
You need to let stable know the git commit id of the patch in Linus's tree if the cc: stable is not on the final commit that gets merged.
thanks,
greg k-h
linux-stable-mirror@lists.linaro.org