From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752511AbcFJGaa (ORCPT ); Fri, 10 Jun 2016 02:30:30 -0400 Received: from shards.monkeyblade.net ([149.20.54.216]:54044 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751203AbcFJGa2 (ORCPT ); Fri, 10 Jun 2016 02:30:28 -0400 Date: Thu, 09 Jun 2016 23:30:25 -0700 (PDT) Message-Id: <20160609.233025.1997097561663090020.davem@davemloft.net> To: dhowells@redhat.com Cc: netdev@vger.kernel.org, linux-afs@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] rxrpc: Simplify connect() implementation and simplify sendmsg() op From: David Miller In-Reply-To: <146550977184.3563.9271906788876997357.stgit@warthog.procyon.org.uk> References: <146550977184.3563.9271906788876997357.stgit@warthog.procyon.org.uk> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (shards.monkeyblade.net [149.20.54.216]); Thu, 09 Jun 2016 23:30:28 -0700 (PDT) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: David Howells Date: Thu, 09 Jun 2016 23:02:51 +0100 > Simplify the RxRPC connect() implementation. It will just note the > destination address it is given, and if a sendmsg() comes along with no > address, this will be assigned as the address. No transport struct will be > held internally, which will allow us to remove this later. > > Simplify sendmsg() also. Whilst a call is active, userspace refers to it > by a private unique user ID specified in a control message. When sendmsg() > sees a user ID that doesn't map to an extant call, it creates a new call > for that user ID and attempts to add it. If, when we try to add it, the > user ID is now registered, we now reject the message with -EEXIST. We > should never see this situation unless two threads are racing, trying to > create a call with the same ID - which would be an error. > > It also isn't required to provide sendmsg() with an address - provided the > control message data holds a user ID that maps to a currently active call. > > Signed-off-by: David Howells Applied to net-next, thanks.