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).
-- james s
Signed-off-by: James Smart <James.Smart@xxxxxxxxxx>
diff -upNr a/drivers/scsi/scsi_transport_fc.c b/drivers/scsi/scsi_transport_fc.c
--- a/drivers/scsi/scsi_transport_fc.c 2007-03-12 13:56:16.000000000 -0500
+++ b/drivers/scsi/scsi_transport_fc.c 2007-03-12 14:25:58.000000000 -0500
@@ -2156,14 +2156,18 @@ fc_remote_port_delete(struct fc_rport *
spin_lock_irqsave(shost->host_lock, flags);
- /* If no scsi target id mapping, delete it */
- if (rport->scsi_target_id == -1) {
- list_del(&rport->peers);
- rport->port_state = FC_PORTSTATE_DELETED;
- fc_queue_work(shost, &rport->rport_delete_work);
- spin_unlock_irqrestore(shost->host_lock, flags);
- return;
- }
+ /*
+ * In the past, we if this was not an FCP-Target, we would
+ * unconditionally just jump to deleting the rport.
+ * However, rports can be used as node containers by the LLDD,
+ * and its not appropriate to just terminate the rport at the
+ * first sign of a loss in connectivity. The LLDD may want to
+ * send ELS traffic to re-validate the login. If the rport is
+ * immediately deleted, it makes it inappropriate for a node
+ * container.
+ * So... we now unconditionally wait dev_loss_tmo before
+ * destroying an rport.
+ */
rport->port_state = FC_PORTSTATE_BLOCKED;
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
