diff options
author | Yi Zou <yi.zou@intel.com> | 2012-09-24 11:52:50 -0700 |
---|---|---|
committer | James Bottomley <JBottomley@Parallels.com> | 2012-10-07 11:52:55 +0100 |
commit | 3b64b1881143ce9e461c211cc81acc72d0cdc476 (patch) | |
tree | 4a4869002d37f8b3257ae442caa67b5071e69fed /Documentation | |
parent | 31c37a6f21d86e6bca095b71d603ed543ae070ad (diff) | |
download | op-kernel-dev-3b64b1881143ce9e461c211cc81acc72d0cdc476.zip op-kernel-dev-3b64b1881143ce9e461c211cc81acc72d0cdc476.tar.gz |
[SCSI] libfc: fix lun reset failure bugs in fc_fcp_resp handling of FCP_RSP_INFO
In LUN RESET testing involving NetApp targets, it is observed that LUN
RESET is failing. The fc_fcp_resp() is not completing the completion
for the LUN RESET task since fc_fcp_resp assumes that the FCP_RSP_INFO
is 8 bytes with the 4 byte reserved field, where in case of NetApp targets
the FCP_RSP to LUN RESET only has 4 bytes of FCP_RSP_INFO. This leads
fc_fcp_resp to error out w/o completing the task completion, eventually
causing LUN RESET to be escalated to host reset, which is not very nice.
Per FCP-3 r04, clause 9.5.15 and Table 23, the FCP_RSP_INFO field can be either
4 bytes or 8 bytes, with the last 4 bytes as "Reserved (if any)". Therefore it
is valid to have 4 bytes FCP_RSP_INFO like some of the NetApp targets behave.
Fixing this by validating the FCP_RSP_INFO against both the two spec allowed
length.
Reported-by: Frank Zhang <frank_1.zhang@intel.com>
Signed-off-by: Yi Zou <yi.zou@intel.com>
Tested-by: Ross Brattain <ross.b.brattain@intel.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Diffstat (limited to 'Documentation')
0 files changed, 0 insertions, 0 deletions