aboutsummaryrefslogtreecommitdiffstats
path: root/include/scsi/fc/fc_gs.h
diff options
context:
space:
mode:
authorJoe Eykholt <jeykholt@cisco.com>2009-08-25 14:02:27 -0700
committerJames Bottomley <James.Bottomley@suse.de>2009-09-10 12:07:50 -0500
commit883a337cf8969b2906ffd8aeb838d875f7338190 (patch)
treeda818ca65c3c1726d0af4521b8069d2f0cf73b20 /include/scsi/fc/fc_gs.h
parent[SCSI] libfc: rearrange code in fc_disc_gpn_ft_resp() (diff)
downloadlinux-dev-883a337cf8969b2906ffd8aeb838d875f7338190.tar.xz
linux-dev-883a337cf8969b2906ffd8aeb838d875f7338190.zip
[SCSI] libfc: handle discovery failure more correctly.
Abhijeet Joglekar wrote: "In gpn_ft_resp, if the payload is short, or unexpected response or out of sequence frame, then we just return and do nothing. We should either enter fc_disc_done() with DISC_EV_FAIL which will then restart any queued discovery requests or call lport module which will reset local port, or we should call fc_disc_error() so that the gpn_ft is retried. The situation as is causes discovery to remain pending and never get restarted, in these rare cases. We saw this due to a coding bug in fc_disc before. The only ways it could happen would be bugs, packet corruption or an FC fabric problem. Change it to fail discovery. The local port will restart discovery, although it probably should just give up until the next link flap. Signed-off-by: Joe Eykholt <jeykholt@cisco.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
Diffstat (limited to 'include/scsi/fc/fc_gs.h')
0 files changed, 0 insertions, 0 deletions