scsi: lpfc: Fix retry of PRLI when status indicates its unsupported
authorDick Kennedy <dick.kennedy@broadcom.com>
Mon, 3 Aug 2020 21:02:26 +0000 (14:02 -0700)
committerMartin K. Petersen <martin.petersen@oracle.com>
Wed, 5 Aug 2020 00:56:57 +0000 (20:56 -0400)
commit678768da988081a922b0645b9bd552f6cdd982cc
tree1dcef731df8f02fa50f3c3fbba3fa27aaa26e78c
parent24411fcd6fe7b55d1a48b80a9ffeb3564ff029a7
scsi: lpfc: Fix retry of PRLI when status indicates its unsupported

With port bounce/address swaps and timing between initiator GID queries vs
remote port FC4 support registrations, the driver may be in a situation
where it sends PRLIs for both FCP and NVME even though the target may not
support one of the protocols. In this case, the remote port will reject the
PRLI and usually indicate it does not support the request. However, the
driver currently ignores the status of the failure and immediately retries
the PRLI, which is pointless. In the case of this one remote port, the
reception of the PRLI retry caused it to decide to send a LOGO.  The LOGO
restarted the process and the same results happened. It made the remote
port undiscoverable to either protocol.

Add logic to detect the non-support status and not attempt the retry
of the PRLI.

Link: https://lore.kernel.org/r/20200803210229.23063-6-jsmart2021@gmail.com
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
drivers/scsi/lpfc/lpfc_els.c