diff options
author | Yi Zou <yi.zou@intel.com> | 2012-07-06 13:40:31 -0400 |
---|---|---|
committer | James Bottomley <JBottomley@Parallels.com> | 2012-07-20 03:58:56 -0400 |
commit | a752359f2b0a291c5f229e883842e4b30c698387 (patch) | |
tree | 6ead324702ca37a69af584be38f31e6d5ecb9f83 /kernel | |
parent | ac166d2fbd2d0c295454bcee7b3c930cb96e72cc (diff) |
[SCSI] libfc: fix sending REC after FCP_RESP is received
This is exposed in the case the FCP_DATA frames somehow got lost and fc_fcp got
the FCP_RSP, in fc_fcp_recv_resp(), since xfer_len is less than the expected_len
it resets the the timer to wait to 2 more jiffies in case the data frames are
already queued locally. However, for target does not support REC, it would just
send RJT w/ ELS_RJT_UNSUP. The rec response handler thus only clears the rport
flag for not doing REC later, but does not do fcp_io_complete() on the
associated fsp.
The fix is just check status of FCP_RSP being received already, i.e. using the
FC_SRB_RCV_STATUS flag, in fc_fcp_timeout before start sending REC. We should
have waited long enough if there is truely data frames queued locally.
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 'kernel')
0 files changed, 0 insertions, 0 deletions