scsi: storvsc: Fix handling of virtual Fibre Channel timeouts

jira LE-1907
Rebuild_History Non-Buildable kernel-5.14.0-284.30.1.el9_2
commit-author Michael Kelley <[email protected]>
commit 175544a
Empty-Commit: Cherry-Pick Conflicts during history rebuild.
Will be included in final tarball splat. Ref for failed cherry-pick at:
ciq/ciq_backports/kernel-5.14.0-284.30.1.el9_2/175544ad.failed

Hyper-V provides the ability to connect Fibre Channel LUNs to the host
system and present them in a guest VM as a SCSI device. I/O to the vFC
device is handled by the storvsc driver. The storvsc driver includes a
partial integration with the FC transport implemented in the generic
portion of the Linux SCSI subsystem so that FC attributes can be displayed
in /sys.  However, the partial integration means that some aspects of vFC
don't work properly. Unfortunately, a full and correct integration isn't
practical because of limitations in what Hyper-V provides to the guest.

In particular, in the context of Hyper-V storvsc, the FC transport timeout
function fc_eh_timed_out() causes a kernel panic because it can't find the
rport and dereferences a NULL pointer. The original patch that added the
call from storvsc_eh_timed_out() to fc_eh_timed_out() is faulty in this
regard.

In many cases a timeout is due to a transient condition, so the situation
can be improved by just continuing to wait like with other I/O requests
issued by storvsc, and avoiding the guaranteed panic. For a permanent
failure, continuing to wait may result in a hung thread instead of a panic,
which again may be better.

So fix the panic by removing the storvsc call to fc_eh_timed_out().  This
allows storvsc to keep waiting for a response.  The change has been tested
by users who experienced a panic in fc_eh_timed_out() due to transient
timeouts, and it solves their problem.

In the future we may want to deprecate the vFC functionality in storvsc
since it can't be fully fixed. But it has current users for whom it is
working well enough, so it should probably stay for a while longer.

Fixes: 3930d73 ("scsi: storvsc: use default I/O timeout handler for FC devices")
	Cc: [email protected]
	Signed-off-by: Michael Kelley <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
	Signed-off-by: Martin K. Petersen <[email protected]>
(cherry picked from commit 175544a)
	Signed-off-by: Jonathan Maple <[email protected]>

# Conflicts:
#	drivers/scsi/storvsc_drv.c

Author: PlaidCat

ciq/ciq_backports/kernel-5.14.0-284.30.1.el9_2/175544ad.failed

@@ -0,0 +1,74 @@
+scsi: storvsc: Fix handling of virtual Fibre Channel timeouts
+
+jira LE-1907
+Rebuild_History Non-Buildable kernel-5.14.0-284.30.1.el9_2
+commit-author Michael Kelley <[email protected]>
+commit 175544ad48cbf56affeef2a679c6a4d4fb1e2881
+Empty-Commit: Cherry-Pick Conflicts during history rebuild.
+Will be included in final tarball splat. Ref for failed cherry-pick at:
+ciq/ciq_backports/kernel-5.14.0-284.30.1.el9_2/175544ad.failed
+
+Hyper-V provides the ability to connect Fibre Channel LUNs to the host
+system and present them in a guest VM as a SCSI device. I/O to the vFC
+device is handled by the storvsc driver. The storvsc driver includes a
+partial integration with the FC transport implemented in the generic
+portion of the Linux SCSI subsystem so that FC attributes can be displayed
+in /sys.  However, the partial integration means that some aspects of vFC
+don't work properly. Unfortunately, a full and correct integration isn't
+practical because of limitations in what Hyper-V provides to the guest.
+
+In particular, in the context of Hyper-V storvsc, the FC transport timeout
+function fc_eh_timed_out() causes a kernel panic because it can't find the
+rport and dereferences a NULL pointer. The original patch that added the
+call from storvsc_eh_timed_out() to fc_eh_timed_out() is faulty in this
+regard.
+
+In many cases a timeout is due to a transient condition, so the situation
+can be improved by just continuing to wait like with other I/O requests
+issued by storvsc, and avoiding the guaranteed panic. For a permanent
+failure, continuing to wait may result in a hung thread instead of a panic,
+which again may be better.
+
+So fix the panic by removing the storvsc call to fc_eh_timed_out().  This
+allows storvsc to keep waiting for a response.  The change has been tested
+by users who experienced a panic in fc_eh_timed_out() due to transient
+timeouts, and it solves their problem.
+
+In the future we may want to deprecate the vFC functionality in storvsc
+since it can't be fully fixed. But it has current users for whom it is
+working well enough, so it should probably stay for a while longer.
+
+Fixes: 3930d7309807 ("scsi: storvsc: use default I/O timeout handler for FC devices")
+	Cc: [email protected]
+	Signed-off-by: Michael Kelley <[email protected]>
+Link: https://lore.kernel.org/r/[email protected]
+	Signed-off-by: Martin K. Petersen <[email protected]>
+(cherry picked from commit 175544ad48cbf56affeef2a679c6a4d4fb1e2881)
+	Signed-off-by: Jonathan Maple <[email protected]>
+
+# Conflicts:
+#	drivers/scsi/storvsc_drv.c
+diff --cc drivers/scsi/storvsc_drv.c
+index a8be138fda6e,047ffaf7d42a..000000000000
+--- a/drivers/scsi/storvsc_drv.c
++++ b/drivers/scsi/storvsc_drv.c
+@@@ -1656,13 -1672,9 +1656,17 @@@ static int storvsc_host_reset_handler(s
+   * be unbounded on Azure.  Reset the timer unconditionally to give the host a
+   * chance to perform EH.
+   */
+ -static enum scsi_timeout_action storvsc_eh_timed_out(struct scsi_cmnd *scmnd)
+ +static enum blk_eh_timer_return storvsc_eh_timed_out(struct scsi_cmnd *scmnd)
+  {
+++<<<<<<< HEAD
+ +#if IS_ENABLED(CONFIG_SCSI_FC_ATTRS)
+ +	if (scmnd->device->host->transportt == fc_transport_template)
+ +		return fc_eh_timed_out(scmnd);
+ +#endif
+ +	return BLK_EH_RESET_TIMER;
+++=======
++ 	return SCSI_EH_RESET_TIMER;
+++>>>>>>> 175544ad48cb (scsi: storvsc: Fix handling of virtual Fibre Channel timeouts)
+  }
+  
+  static bool storvsc_scsi_cmd_ok(struct scsi_cmnd *scmnd)
+* Unmerged path drivers/scsi/storvsc_drv.c