scsi: storvsc: Fix handling of virtual Fibre Channel timeouts

In the Linux kernel, the following vulnerability has been resolved:

scsi: storvsc: Fix handling of virtual Fibre Channel timeouts

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.