On 07/01/13 11:25, Sebastian Riemer wrote:
On 28.06.2013 14:49, Bart Van Assche wrote:
If reconnecting failed we know that no command completion will
be received anymore. Hence let the SCSI error handler fail such
commands immediately.
Signed-off-by: Bart Van Assche <bvanass...@acm.org>
Cc: Roland Dreier <rol...@purestorage.com>
Cc: David Dillow <dillo...@ornl.gov>
Cc: Sebastian Riemer <sebastian.rie...@profitbricks.com>
Cc: Vu Pham <v...@mellanox.com>
---
drivers/infiniband/ulp/srp/ib_srp.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/infiniband/ulp/srp/ib_srp.c
b/drivers/infiniband/ulp/srp/ib_srp.c
index 8c95262..5c91521 100644
--- a/drivers/infiniband/ulp/srp/ib_srp.c
+++ b/drivers/infiniband/ulp/srp/ib_srp.c
@@ -1755,6 +1755,8 @@ static int srp_abort(struct scsi_cmnd *scmnd)
if (srp_send_tsk_mgmt(target, req->index, scmnd->device->lun,
SRP_TSK_ABORT_TASK) == 0)
ret = SUCCESS;
+ else if (target->transport_offline)
+ ret = FAST_IO_FAIL;
else
ret = FAILED;
srp_free_req(target, req, scmnd, 0);
I'm also missing the concept for srp_reset_device(). There is a very
common case that the SCSI error handling and the transport layer error
handling run in parallel: Congestion.
Can you explain this comment further, and also how this comment relates
to patch 04/15 ?
In congestion some LUNs are blocked while others can still transmit. A
little bit later the QP timeout triggers in the middle of the SCSI error
handling in srp_abort(), srp_reset_device() or less likely in
srp_reset_host().
I am aware this can result in concurrent srp_reconnect_rport() calls.
However, such concurrent calls are serialized via rport->mutex.
Bart.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
