From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sebastian Riemer Subject: Re: [PATCH v2 04/15] IB/srp: Fail I/O fast if target offline Date: Mon, 01 Jul 2013 14:31:49 +0200 Message-ID: <51D176B5.90609@profitbricks.com> References: <51CD856A.3010102@acm.org> <51CD8676.6080205@acm.org> <51D14AF1.4000803@profitbricks.com> <51D16A39.4050709@acm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <51D16A39.4050709-HInyCGIudOg@public.gmane.org> Sender: linux-rdma-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Bart Van Assche Cc: Roland Dreier , David Dillow , Vu Pham , linux-rdma List-Id: linux-rdma@vger.kernel.org On 01.07.2013 13:38, Bart Van Assche wrote: >>> --- 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 ? Sorry, found it. Even if only one srp_reset_device() fails, then srp_reset_host() is called anyway. So there this check + returning FAST_IO_FAIL doesn't make so much sense. >> 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. I put my comment regarding this to patch 10. Cheers, Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html