summaryrefslogtreecommitdiff
path: root/Documentation/feature-removal-schedule.txt
diff options
context:
space:
mode:
authorJames Smart <James.Smart@Emulex.Com>2007-04-27 11:53:17 -0400
committerJames Bottomley <jejb@mulgrave.il.steeleye.com>2007-05-06 09:33:20 -0500
commit92740b24ce6ddac6534fae985aab602548692186 (patch)
tree9bee34a7786a0c0b796770b89688cfae70b86ec0 /Documentation/feature-removal-schedule.txt
parentac09c349080008fdd54a15616a1b14771772d867 (diff)
downloadlwn-92740b24ce6ddac6534fae985aab602548692186.tar.gz
lwn-92740b24ce6ddac6534fae985aab602548692186.zip
[SCSI] fc_transport: make all rports wait dev_loss_tmo before removing them
Per the comment in the change - it's not always prudent to immediately remove the rport upon first notice of a disconnect. Make all rports wait dev_loss_tmo before being deleted (and each could have a separate dev_loss_tmo value). The original post was: http://marc.info/?l=linux-scsi&m=117392196006703&w=2 The repost contains the following changes: - Bug fix in fc_starget_delete(). Dev_loss_tmo_callbk() was called prior to tearing down the target. The callback is to be the last thing called, as it tells the LLDD that the rport is completely finished and can be torn down. Rework so that terminate_rport_io() is called to terminate the outstanding io. Isolated work so it's is simply "starget" work. - Fix holes in original patch. There were code paths that did not expect the dev_loss_tmo timer to be running for the non-fcp rports. - Bug Fix: the transport wasn't protecting against a LLDD calling fc_remote_port_delete() back-to-back. Thus, the dev_loss_tmo timer could be restarted such that it fires after the rport had been deleted. Validate rport state before starting the timer. Signed-off-by: James Smart <James.Smart@emulex.com> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Diffstat (limited to 'Documentation/feature-removal-schedule.txt')
0 files changed, 0 insertions, 0 deletions