From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sagi Grimberg Subject: Re: [PATCH 3/3] IB/srpt: Fix a race condition related to SRP login Date: Sun, 3 Jan 2016 13:24:55 +0200 Message-ID: <56890507.9080404@dev.mellanox.co.il> References: <5684ED4B.2010303@sandisk.com> <5684EE16.8070701@sandisk.com> <20160103105127.GA10025@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20160103105127.GA10025-jcswGhMUV9g@public.gmane.org> Sender: linux-rdma-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Christoph Hellwig , Bart Van Assche Cc: Doug Ledford , Sagi Grimberg , "linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" List-Id: linux-rdma@vger.kernel.org > But now the first I/O(s) could be lost if no other I/O comes in, > right? I suspect that we need to keep this loop to protect against > such corner cases. It can happen theoretically, but why do we even bother? Why not just post the recv buffer after we moved in to CH_LIVE? This why we let the RC transport handle the "Recv-Not-Ready" NAK by retrying? -- 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