summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorMike Christie <michaelc@cs.wisc.edu>2010-03-09 14:14:51 -0600
committerJames Bottomley <James.Bottomley@suse.de>2010-03-27 15:02:48 -0400
commit4ae0a6c15efcc37e94e3f30e3533bdec03c53126 (patch)
treedf66736300cb0b7eb41622bb19fc57fd553caf57
parentb72c40949b0f04728f2993a1434598d3bad094ea (diff)
downloadlinux-lfu-4ae0a6c15efcc37e94e3f30e3533bdec03c53126.tar.gz
linux-lfu-4ae0a6c15efcc37e94e3f30e3533bdec03c53126.tar.xz
[SCSI] libiscsi: Fix recovery slowdown regression
We could be failing/stopping a connection due to libiscsi starting recovery/cleanup, but the xmit path or scsi eh thread path could be dropping the connection at the same time. As a result the session->state gets set to failed instead of in recovery. We end up not blocking the session and so the replacement timeout never gets started and we only end up failing the IO when scsi_softirq_done sees that the cmd has been running for (cmd->allowed + 1) * rq->timeout secs. We used to fail the IO right away so users are seeing a long delay when using dm-multipath. This problem was added in 2.6.28. Signed-off-by: Mike Christie <michaelc@cs.wisc.edu> Cc: stable@kernel.org Signed-off-by: James Bottomley <James.Bottomley@suse.de>
-rw-r--r--drivers/scsi/libiscsi.c5
1 files changed, 3 insertions, 2 deletions
diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c
index 685eaec5321..7688b8f83e9 100644
--- a/drivers/scsi/libiscsi.c
+++ b/drivers/scsi/libiscsi.c
@@ -3087,14 +3087,15 @@ static void iscsi_start_session_recovery(struct iscsi_session *session,
session->state = ISCSI_STATE_TERMINATE;
else if (conn->stop_stage != STOP_CONN_RECOVER)
session->state = ISCSI_STATE_IN_RECOVERY;
+
+ old_stop_stage = conn->stop_stage;
+ conn->stop_stage = flag;
spin_unlock_bh(&session->lock);
del_timer_sync(&conn->transport_timer);
iscsi_suspend_tx(conn);
spin_lock_bh(&session->lock);
- old_stop_stage = conn->stop_stage;
- conn->stop_stage = flag;
conn->c_stage = ISCSI_CONN_STOPPED;
spin_unlock_bh(&session->lock);