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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
