[<prev] [next>] [day] [month] [year] [list]
Message-ID: <1828884A29C6694DAF28B7E6B8A82373A903972E@ORSMSX109.amr.corp.intel.com>
Date: Tue, 8 Sep 2015 21:32:07 +0000
From: "Hefty, Sean" <sean.hefty@...el.com>
To: Nicholas Krause <xerofoify@...il.com>,
"dledford@...hat.com" <dledford@...hat.com>
CC: "hal.rosenstock@...il.com" <hal.rosenstock@...il.com>,
"jgunthorpe@...idianresearch.com" <jgunthorpe@...idianresearch.com>,
"Weiny, Ira" <ira.weiny@...el.com>,
"yun.wang@...fitbricks.com" <yun.wang@...fitbricks.com>,
"sagig@...lanox.com" <sagig@...lanox.com>,
"swise@...ngridcomputing.com" <swise@...ngridcomputing.com>,
"Matt@...lanox.com" <Matt@...lanox.com>,
"linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] infiniband:core:Fix assumation that the function
ib_send_cm_drep never fails in rdma_disconnect
> This fixes the incorrect assumation that the function ib_send_cm_drep
> always runs successfully and never fails in the function rdma_disconnect
> by making this call be assigned the variable used to return to callers
> of rdma_disconnect in order to make sure that a error code is returned
> if a failure occurs with this call in order for the caller to handle.
It's not assuming that it doesn't fail. It's saying that it doesn't care that it does. The call to send a DREP is optimistic and correct in most circumstances. The app is done at this point, and the connection has been disconnected.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists