Skip to contentSkip to conversation

FAILED: patch "[PATCH] scsi: zfcp: fix rport unblock if deleted SCSI devices on" failed to apply to 3.18-stable tree

PATCH [email protected] 2 participants 3 messages Mar 30, 2019 – Apr 1, 2019

Subsystems (3)
Stable branch s390 s390 zfcp driver
lore
Share & tools
lore

[email protected]

author maintainer
#0 lore raw

The patch below does not apply to the 3.18-stable tree.
If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <[email protected]>.

thanks,

greg k-h

------------------ original commit in Linus's tree ------------------

From fe67888fc007a76b81e37da23ce5bd8fb95890b0 Mon Sep 17 00:00:00 2001
From: Steffen Maier <[email protected]>
Date: Tue, 26 Mar 2019 14:36:58 +0100
Subject: [PATCH] scsi: zfcp: fix rport unblock if deleted SCSI devices on
Scsi_Host

An already deleted SCSI device can exist on the Scsi_Host and remain there because something still holds a reference. A new SCSI device with the same H:C:T:L and FCP device, target port WWPN, and FCP LUN can be created. When we try to unblock an rport, we still find the deleted SCSI device and return early because the zfcp_scsi_dev of that SCSI device is not ZFCP_STATUS_COMMON_UNBLOCKED. Hence we miss to unblock the rport, even if the new proper SCSI device would be in good state.

Therefore, skip deleted SCSI devices when iterating the sdevs of the shost. [cf. __scsi_device_lookup{_by_target}() or scsi_device_get()]

The following abbreviated trace sequence can indicate such problem:

Area : REC
Tag : ersfs_3
LUN : 0x4045400300000000
WWPN : 0x50050763031bd327
LUN status : 0x40000000 not ZFCP_STATUS_COMMON_UNBLOCKED
Ready count : n not incremented yet
Running count : 0x00000000
ERP want : 0x01
ERP need : 0xc1 ZFCP_ERP_ACTION_NONE

Area : REC
Tag : ersfs_3
LUN : 0x4045400300000000
WWPN : 0x50050763031bd327
LUN status : 0x41000000
Ready count : n+1
Running count : 0x00000000
ERP want : 0x01
ERP need : 0x01

...

Area : REC
Level : 4 only with increased trace level
Tag : ertru_l
LUN : 0x4045400300000000
WWPN : 0x50050763031bd327
LUN status : 0x40000000
Request ID : 0x0000000000000000
ERP status : 0x01800000
ERP step : 0x1000
ERP action : 0x01
ERP count : 0x00

NOT followed by a trace record with tag "scpaddy"
for WWPN 0x50050763031bd327.

Signed-off-by Steffen Maier <[email protected]>
Fixes 6f2ce1c6af37 ("scsi: zfcp: fix rport unblock race with LUN recovery")
Cc <[email protected]> #2.6.32+
Reviewed-by Jens Remus <[email protected]>
Reviewed-by Benjamin Block <[email protected]>
Signed-off-by Martin K. Petersen <[email protected]>
drivers/s390/scsi/zfcp_erp.c +3 -0
index 744a64680d5b..c0b2348d7ce6 100644
@@ -1341,6 +1341,9 @@ static void zfcp_erp_try_rport_unblock(struct zfcp_port *port)
 		struct zfcp_scsi_dev *zsdev = sdev_to_zfcp(sdev);
 		int lun_status;
 
+		if (sdev->sdev_state == SDEV_DEL ||
+		    sdev->sdev_state == SDEV_CANCEL)
+			continue;
 		if (zsdev->port != port)
 			continue;
 		/* LUN under port of interest */
#1 lore raw
Quoted 4 lines · On 3/30/19 11:13 AM, [email protected] wrote:

The patch below does not apply to the 3.18-stable tree.
If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <[email protected]>.

The commit that this one fixes does not seem to be in 3.18-stable, so this one does not apply and is not necessary. It's OK to live without them in 3.18.

Quoted 80 lines

------------------ original commit in Linus's tree ------------------

From fe67888fc007a76b81e37da23ce5bd8fb95890b0 Mon Sep 17 00:00:00 2001
From: Steffen Maier <[email protected]>
Date: Tue, 26 Mar 2019 14:36:58 +0100
Subject: [PATCH] scsi: zfcp: fix rport unblock if deleted SCSI devices on
Scsi_Host

An already deleted SCSI device can exist on the Scsi_Host and remain there because something still holds a reference. A new SCSI device with the same H:C:T:L and FCP device, target port WWPN, and FCP LUN can be created. When we try to unblock an rport, we still find the deleted SCSI device and return early because the zfcp_scsi_dev of that SCSI device is not ZFCP_STATUS_COMMON_UNBLOCKED. Hence we miss to unblock the rport, even if the new proper SCSI device would be in good state.

Therefore, skip deleted SCSI devices when iterating the sdevs of the shost. [cf. __scsi_device_lookup{_by_target}() or scsi_device_get()]

The following abbreviated trace sequence can indicate such problem:

Area : REC
Tag : ersfs_3
LUN : 0x4045400300000000
WWPN : 0x50050763031bd327
LUN status : 0x40000000 not ZFCP_STATUS_COMMON_UNBLOCKED
Ready count : n not incremented yet
Running count : 0x00000000
ERP want : 0x01
ERP need : 0xc1 ZFCP_ERP_ACTION_NONE

Area : REC
Tag : ersfs_3
LUN : 0x4045400300000000
WWPN : 0x50050763031bd327
LUN status : 0x41000000
Ready count : n+1
Running count : 0x00000000
ERP want : 0x01
ERP need : 0x01

...

Area : REC
Level : 4 only with increased trace level
Tag : ertru_l
LUN : 0x4045400300000000
WWPN : 0x50050763031bd327
LUN status : 0x40000000
Request ID : 0x0000000000000000
ERP status : 0x01800000
ERP step : 0x1000
ERP action : 0x01
ERP count : 0x00

NOT followed by a trace record with tag "scpaddy"
for WWPN 0x50050763031bd327.

Signed-off-by Steffen Maier <[email protected]>
Fixes 6f2ce1c6af37 ("scsi: zfcp: fix rport unblock race with LUN recovery")
Cc <[email protected]> #2.6.32+
Reviewed-by Jens Remus <[email protected]>
Reviewed-by Benjamin Block <[email protected]>
Signed-off-by Martin K. Petersen <[email protected]>
drivers/s390/scsi/zfcp_erp.c +3 -0
index 744a64680d5b..c0b2348d7ce6 100644
@@ -1341,6 +1341,9 @@ static void zfcp_erp_try_rport_unblock(struct zfcp_port *port)
  		struct zfcp_scsi_dev *zsdev = sdev_to_zfcp(sdev);
  		int lun_status;
 
+		if (sdev->sdev_state == SDEV_DEL ||
+		    sdev->sdev_state == SDEV_CANCEL)
+			continue;
  		if (zsdev->port != port)
  			continue;
  		/* LUN under port of interest */
Signature · 11 lines
Mit freundlichen Gruessen / Kind regards
Steffen Maier

Linux on IBM Z Development

https://www.ibm.com/privacy/us/en/
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Matthias Hartmann
Geschaeftsfuehrung: Dirk Wittkopp
Sitz der Gesellschaft: Boeblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
author maintainer
#2 lore raw
Quoted 9 lines · Steffen Maier
Quoted 4 lines · On 3/30/19 11:13 AM, [email protected] wrote:

The patch below does not apply to the 3.18-stable tree.
If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <[email protected]>.

The commit that this one fixes does not seem to be in 3.18-stable, so this one does not apply and is not necessary. It's OK to live without them in 3.18.

Ok, thanks for looking.

greg k-h