From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-f68.google.com (mail-wr1-f68.google.com [209.85.221.68]) by mail19.linbit.com (LINBIT Mail Daemon) with ESMTP id 59BB8420424 for ; Sat, 13 Jun 2020 11:58:38 +0200 (CEST) Received: by mail-wr1-f68.google.com with SMTP id x6so12245022wrm.13 for ; Sat, 13 Jun 2020 02:58:38 -0700 (PDT) Received: from soda.linbit (62-99-137-214.static.upcbusiness.at. [62.99.137.214]) by smtp.gmail.com with ESMTPSA id i8sm13403726wru.30.2020.06.13.02.58.37 for (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Sat, 13 Jun 2020 02:58:37 -0700 (PDT) Resent-Message-ID: <20200613095835.GU4222@soda.linbit> Received: from mail-qt1-f193.google.com (mail-qt1-f193.google.com [209.85.160.193]) by mail19.linbit.com (LINBIT Mail Daemon) with ESMTP id E33974203D6 for ; Thu, 21 May 2020 15:54:47 +0200 (CEST) Received: by mail-qt1-f193.google.com with SMTP id v4so5517538qte.3 for ; Thu, 21 May 2020 06:54:47 -0700 (PDT) From: Marcelo Ricardo Leitner To: Christoph Hellwig Message-ID: <20200521135443.GY2491@localhost.localdomain> References: <20200520195509.2215098-1-hch@lst.de> <20200520195509.2215098-33-hch@lst.de> <20200520230025.GT2491@localhost.localdomain> <20200521084224.GA7859@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200521084224.GA7859@lst.de> Cc: Eric Dumazet , linux-nvme@lists.infradead.org, linux-sctp@vger.kernel.org, target-devel@vger.kernel.org, linux-afs@lists.infradead.org, drbd-dev@lists.linbit.com, linux-cifs@vger.kernel.org, rds-devel@oss.oracle.com, linux-rdma@vger.kernel.org, cluster-devel@redhat.com, Alexey Kuznetsov , Jakub Kicinski , ceph-devel@vger.kernel.org, linux-nfs@vger.kernel.org, Neil Horman , Hideaki YOSHIFUJI , netdev@vger.kernel.org, Vlad Yasevich , linux-kernel@vger.kernel.org, Jon Maloy , Ying Xue , "David S. Miller" , ocfs2-devel@oss.oracle.com Subject: Re: [Drbd-dev] [PATCH 32/33] net: add a new bind_add method List-Id: "*Coordination* of development, patches, contributions -- *Questions* \(even to developers\) go to drbd-user, please." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Sat, 13 Jun 2020 10:18:17 -0000 On Thu, May 21, 2020 at 10:42:24AM +0200, Christoph Hellwig wrote: > On Wed, May 20, 2020 at 08:00:25PM -0300, Marcelo Ricardo Leitner wrote: > > > + if (err) > > > + return err; > > > + > > > + lock_sock(sk); > > > + err = sctp_do_bind(sk, (union sctp_addr *)addr, af->sockaddr_len); > > > + if (!err) > > > + err = sctp_send_asconf_add_ip(sk, addr, 1); > > > > Some problems here. > > - addr may contain a list of addresses > > - the addresses, then, are not being validated > > - sctp_do_bind may fail, on which it requires some undoing > > (like sctp_bindx_add does) > > - code duplication with sctp_setsockopt_bindx. > > sctp_do_bind and thus this function only support a single address, as > that is the only thing that the DLM code requires. I could move the I see. > user copy out of sctp_setsockopt_bindx and reuse that, but it is a > rather rcane API. Yes. With David's patch, which is doing that, it can be as simple as: static int sctp_bind_add(struct sock *sk, struct sockaddr *addr, int addrlen) { int ret; lock_sock(sk); ret = sctp_setsockopt_bindx(sk, addr, addrlen, SCTP_BINDX_ADD_ADDR); release_sock(sk); return ret; } and then dlm would be using code that we can test through sctp-only tests as well. > > > > > This patch will conflict with David's one, > > [PATCH net-next] sctp: Pull the user copies out of the individual sockopt functions. > > Do you have a link? A quick google search just finds your mail that > I'm replying to. https://lore.kernel.org/netdev/fd94b5e41a7c4edc8f743c56a04ed2c9%40AcuMS.aculab.com/T/ > > > (I'll finish reviewing it in the sequence) > > > > AFAICT, this patch could reuse/build on his work in there. The goal is > > pretty much the same and would avoid the issues above. > > > > This patch could, then, point the new bind_add proto op to the updated > > sctp_setsockopt_bindx almost directly. > > > > Question then is: dlm never removes an addr from the bind list. Do we > > want to add ops for both? Or one that handles both operations? > > Anyhow, having the add operation but not the del seems very weird to > > me. > > We generally only add operations for things that we actually use. > bind_del is another logical op, but we can trivially add that when we > need it. Right, okay.