Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp1223186ybk; Thu, 14 May 2020 03:42:39 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx1JRqjqnGykARXUYAzLfhhaZcIOhZmilGekmvpyxbmmvKJbTSKbamUUaXsBzaYGHVmFFSY X-Received: by 2002:a50:ee04:: with SMTP id g4mr3293879eds.221.1589452959817; Thu, 14 May 2020 03:42:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1589452959; cv=none; d=google.com; s=arc-20160816; b=DBJxUUGT+gmsk9ex68b4bf/emoo995RIac67+aEGODHQDMLEx2q2r+Qyd/vsf2UGrt cEY55AS7tHtwH/rveRMx6qJ0PFBPV2oHIPo77WmGT5TLxj39f5qFQ7bjodYorqLqoHXU 8CGTEDY7vtaqQV7W0bs/QXCYlyqzTnz6aJoXtk++dM8ezSfumwngXL26AE+ah4rr6f3Q yCTeTpuU7ngXxffm9ebaGKaWocWsDnmRv/6ow3ImnsislZtZMl3IeXcLMsbBqcCV35x2 pjJwwPpjXO5nL0DyZw88T8VI7hr+I1w9t+Kkyp4Nh4P4KLo430d4ysPY22fKPR897nbl L32w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=cO1klLCsVIpTTF7xIJ30kb3wDCYY5t3XDUTmpVJxndM=; b=0VRtfyILeWEILVF+wzZUXryEkJcku7hFwoCLnLzvYMKFLR1Y28a7UxWMVMjXekjmy8 JZ9u7yNben/j1uOomi7mKkaWFvVxWU0RX2ZF9MjUYA+K+dX4AtqeAWhRDUKCwFaTXrrE YtKwVWtnpc3Q35Maz1whmUS+mPjXUFLzDP1k5URNViR4afCx4JfbEMXDk59ChVbhgr3h zElHVo7oEy92cXcR/21L0wHw3mn7wSbhFSO/H9WzPYE8hL+AjTRbQTZAI/IPGLpQrJUD u8p6pOR4Nd2sXrXmIRzZj9iAZZwYmckxFdk7guHiGcbCCcQ7YBB6TRIBYAcgpDxXDL7A e29w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id rl1si1568420ejb.167.2020.05.14.03.42.14; Thu, 14 May 2020 03:42:39 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726332AbgENKkp (ORCPT + 99 others); Thu, 14 May 2020 06:40:45 -0400 Received: from verein.lst.de ([213.95.11.211]:51250 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725978AbgENKkp (ORCPT ); Thu, 14 May 2020 06:40:45 -0400 Received: by verein.lst.de (Postfix, from userid 2407) id 8A1C268BEB; Thu, 14 May 2020 12:40:40 +0200 (CEST) Date: Thu, 14 May 2020 12:40:40 +0200 From: Christoph Hellwig To: Marcelo Ricardo Leitner , Christine Caulfield , David Teigland Cc: Christoph Hellwig , "David S. Miller" , Jakub Kicinski , Eric Dumazet , Alexey Kuznetsov , Hideaki YOSHIFUJI , Vlad Yasevich , Neil Horman , Jon Maloy , Ying Xue , drbd-dev@lists.linbit.com, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, linux-rdma@vger.kernel.org, linux-nvme@lists.infradead.org, target-devel@vger.kernel.org, linux-afs@lists.infradead.org, linux-cifs@vger.kernel.org, cluster-devel@redhat.com, ocfs2-devel@oss.oracle.com, netdev@vger.kernel.org, linux-sctp@vger.kernel.org, ceph-devel@vger.kernel.org, rds-devel@oss.oracle.com, linux-nfs@vger.kernel.org Subject: is it ok to always pull in sctp for dlm, was: Re: [PATCH 27/33] sctp: export sctp_setsockopt_bindx Message-ID: <20200514104040.GA12979@lst.de> References: <20200513062649.2100053-1-hch@lst.de> <20200513062649.2100053-28-hch@lst.de> <20200513180058.GB2491@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200513180058.GB2491@localhost.localdomain> User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-nfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org On Wed, May 13, 2020 at 03:00:58PM -0300, Marcelo Ricardo Leitner wrote: > On Wed, May 13, 2020 at 08:26:42AM +0200, Christoph Hellwig wrote: > > And call it directly from dlm instead of going through kernel_setsockopt. > > The advantage on using kernel_setsockopt here is that sctp module will > only be loaded if dlm actually creates a SCTP socket. With this > change, sctp will be loaded on setups that may not be actually using > it. It's a quite big module and might expose the system. > > I'm okay with the SCTP changes, but I'll defer to DLM folks to whether > that's too bad or what for DLM. So for ipv6 I could just move the helpers inline as they were trivial and avoid that issue. But some of the sctp stuff really is way too big for that, so the only other option would be to use symbol_get.