scsi: zfcp: Defer fc_rport blocking until after ADISC response
authorSteffen Maier <maier@linux.ibm.com>
Mon, 24 Jul 2023 14:51:56 +0000 (16:51 +0200)
committerMartin K. Petersen <martin.petersen@oracle.com>
Wed, 26 Jul 2023 01:54:05 +0000 (21:54 -0400)
commite65851989001c0c9ba9177564b13b38201c0854c
treeb2fcfc9962c5d4d27302e7c971dffd8dabe945a0
parent010c1e1c5741365dbbf44a5a5bb9f30192875c4c
scsi: zfcp: Defer fc_rport blocking until after ADISC response

Storage devices are free to send RSCNs, e.g. for internal state changes. If
this happens on all connected paths, zfcp risks temporarily losing all
paths at the same time. This has strong requirements on multipath
configuration such as "no_path_retry queue".

Avoid such situations by deferring fc_rport blocking until after the ADISC
response, when any actual state change of the remote port became clear.
The already existing port recovery triggers explicitly block the fc_rport.
The triggers are: on ADISC reject or timeout (typical cable pull case), and
on ADISC indicating that the remote port has changed its WWPN or
the port is meanwhile no longer open.

As a side effect, this also removes a confusing direct function call to
another work item function zfcp_scsi_rport_work() instead of scheduling
that other work item. It was probably done that way to have the rport block
side effect immediate and synchronous to the caller.

Fixes: a2fa0aede07c ("[SCSI] zfcp: Block FC transport rports early on errors")
Cc: stable@vger.kernel.org #v2.6.30+
Reviewed-by: Benjamin Block <bblock@linux.ibm.com>
Reviewed-by: Fedor Loshakov <loshakov@linux.ibm.com>
Signed-off-by: Steffen Maier <maier@linux.ibm.com>
Link: https://lore.kernel.org/r/20230724145156.3920244-1-maier@linux.ibm.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
drivers/s390/scsi/zfcp_fc.c