Skip to contentSkip to conversation

lpfc: correct device removal deadlock after link bounce

PATCH Applied James Smart 4 participants 4 messages Dec 30, 2014 – Jan 5, 2015

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

PATCH 1/1 lpfc: correct device removal deadlock after link bounce

This patch, applicable to 8G/4G/2G adapters, adds a call that resumes transmit operations after a link bounce. Without it, targets that tried to suspend exchanges after a link bounce (such as tape devices using sequence level error recovery) would never resume io operation, causing scan failures, and eventually deadlocks if a device removal request is made.

The patches were cut against Christoph's scsi-queue.git, branch "drivers-for-3.18". The driver rev cut against is 10.4.8000.0

-- james s

---
 lpfc_els.c |    9 +++++++++
 1 file changed, 9 insertions(+)
drivers/scsi/lpfc/lpfc_els.c +9 -0
diff -upNr a/drivers/scsi/lpfc/lpfc_els.c b/drivers/scsi/lpfc/lpfc_els.c
@@ -2225,6 +2225,15 @@ lpfc_adisc_done(struct lpfc_vport *vport
 	if ((phba->sli3_options & LPFC_SLI3_NPIV_ENABLED) &&
 	    !(vport->fc_flag & FC_RSCN_MODE) &&
 	    (phba->sli_rev < LPFC_SLI_REV4)) {
+		/* The ADISCs are complete.  Doesn't matter if they
+		 * succeeded or failed because the ADISC completion
+		 * routine guarantees to call the state machine and
+		 * the RPI is either unregistered (failed ADISC response)
+		 * or the RPI is still valid and the node is marked
+		 * mapped for a target.  The exchanges should be in the
+		 * correct state. This code is specific to SLI3.
+		 */
+		lpfc_issue_clear_la(phba, vport);
 		lpfc_issue_reg_vpi(phba, vport);
 		return;
 	}
#1 lore raw

This patch was tested in house at Red Hat and is running in test kernels at a couple of Red Hat customers.
James, thanks for sending it upstream.
Laurence

Quoted 44 lines · James Smart

This patch, applicable to 8G/4G/2G adapters, adds a call that resumes transmit operations after a link bounce. Without it, targets that tried to suspend exchanges after a link bounce (such as tape devices using sequence level error recovery) would never resume io operation, causing scan failures, and eventually deadlocks if a device removal request is made.

The patches were cut against Christoph's scsi-queue.git, branch "drivers-for-3.18". The driver rev cut against is 10.4.8000.0

-- james s

---
 lpfc_els.c |    9 +++++++++
 1 file changed, 9 insertions(+)

diff -upNr a/drivers/scsi/lpfc/lpfc_els.c b/drivers/scsi/lpfc/lpfc_els.c

drivers/scsi/lpfc/lpfc_els.c 2014-12-30 11:23:04.344426606 -0500 renamed from drivers/scsi/lpfc/lpfc_els.c 2014-12-29 12:48:08.000000000 -0500 +9 -1
@@ -2225,6 +2225,15 @@ lpfc_adisc_done(struct lpfc_vport *vport
        if ((phba->sli3_options & LPFC_SLI3_NPIV_ENABLED) &&
            !(vport->fc_flag & FC_RSCN_MODE) &&
            (phba->sli_rev < LPFC_SLI_REV4)) {
+               /* The ADISCs are complete.  Doesn't matter if they
+                * succeeded or failed because the ADISC completion
+                * routine guarantees to call the state machine and
+                * the RPI is either unregistered (failed ADISC response)
+                * or the RPI is still valid and the node is marked
+                * mapped for a target.  The exchanges should be in the
+                * correct state. This code is specific to SLI3.
+                */
+               lpfc_issue_clear_la(phba, vport);
                lpfc_issue_reg_vpi(phba, vport);
                return;
        }
 
 
--

To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Reviewed-by on v1 1/1
#2 lore raw
In reply to James Smart
Quoted 41 lines · James Smart

This patch, applicable to 8G/4G/2G adapters, adds a call that resumes transmit operations after a link bounce. Without it, targets that tried to suspend exchanges after a link bounce (such as tape devices using sequence level error recovery) would never resume io operation, causing scan failures, and eventually deadlocks if a device removal request is made.

The patches were cut against Christoph's scsi-queue.git, branch "drivers-for-3.18". The driver rev cut against is 10.4.8000.0

-- james s

---
 lpfc_els.c |    9 +++++++++
 1 file changed, 9 insertions(+)

diff -upNr a/drivers/scsi/lpfc/lpfc_els.c b/drivers/scsi/lpfc/lpfc_els.c

drivers/scsi/lpfc/lpfc_els.c +9 -1
@@ -2225,6 +2225,15 @@ lpfc_adisc_done(struct lpfc_vport *vport
 	if ((phba->sli3_options & LPFC_SLI3_NPIV_ENABLED) &&
 	    !(vport->fc_flag & FC_RSCN_MODE) &&
 	    (phba->sli_rev < LPFC_SLI_REV4)) {
+		/* The ADISCs are complete.  Doesn't matter if they
+		 * succeeded or failed because the ADISC completion
+		 * routine guarantees to call the state machine and
+		 * the RPI is either unregistered (failed ADISC response)
+		 * or the RPI is still valid and the node is marked
+		 * mapped for a target.  The exchanges should be in the
+		 * correct state. This code is specific to SLI3.
+		 */
+		lpfc_issue_clear_la(phba, vport);
 		lpfc_issue_reg_vpi(phba, vport);
 		return;
 	}
 
 
--
Quoted 3 lines

To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html