From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 43B6CC433E0 for ; Sat, 16 May 2020 15:21:26 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 0D64B20756 for ; Sat, 16 May 2020 15:21:26 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="RGJUaAPm" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0D64B20756 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=ACULAB.COM Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-nvme-bounces+linux-nvme=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:In-Reply-To:References: Message-ID:Date:Subject:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=NJJPlpmdVxwrJbAZ116TTP6MSMOI6zyPw5uEQMJ6eqc=; b=RGJUaAPmUMmlvI HptiZL6pq5EEWBL7YHa0TxCG4lmwv8hwPQKAnqs3xpjEfn/HxRdSqgY5IsGqyCZWSloVj8PMEpMPd 93UznIBQjxBQltcFQqj1HBNVF4E9PwDH1k2QnOyp/IT0NibbNrRgQGTN7OYh9hFEEqhf2BDI7JOYK k4gRy6vMtLAfZdNKyjV0ZYgZfA6bQUctD0rNQuoCW+Fmo0jEAvOU0zXW0gNpZV+0USPAkd4nUuwgx qmSZVIXcvCO2TVLDEMSzo9xome4BYMwV2ACjNH0cxk3A1CDFmv/77+Do5RxYfIScFWvspTH5R8JJN EMzZfqu9nNbnCvPJhukA==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jZycu-0006Q2-5f; Sat, 16 May 2020 15:21:24 +0000 Received: from eu-smtp-delivery-151.mimecast.com ([207.82.80.151]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jZycq-0006PO-C6 for linux-nvme@lists.infradead.org; Sat, 16 May 2020 15:21:21 +0000 Received: from AcuMS.aculab.com (156.67.243.126 [156.67.243.126]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-2-M-or8IPqO3ut6gEkeJwgCw-1; Sat, 16 May 2020 16:21:16 +0100 X-MC-Unique: M-or8IPqO3ut6gEkeJwgCw-1 Received: from AcuMS.Aculab.com (fd9f:af1c:a25b:0:43c:695e:880f:8750) by AcuMS.aculab.com (fd9f:af1c:a25b:0:43c:695e:880f:8750) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Sat, 16 May 2020 16:21:15 +0100 Received: from AcuMS.Aculab.com ([fe80::43c:695e:880f:8750]) by AcuMS.aculab.com ([fe80::43c:695e:880f:8750%12]) with mapi id 15.00.1347.000; Sat, 16 May 2020 16:21:15 +0100 From: David Laight To: 'Christoph Hellwig' , David Howells Subject: RE: [PATCH 27/33] sctp: export sctp_setsockopt_bindx Thread-Topic: [PATCH 27/33] sctp: export sctp_setsockopt_bindx Thread-Index: AQHWKsz+yiOODFVfBEqdWGEpseVc56iq0wgA Date: Sat, 16 May 2020 15:21:15 +0000 Message-ID: References: <20200514062820.GC8564@lst.de> <20200513062649.2100053-1-hch@lst.de> <20200513062649.2100053-28-hch@lst.de> <20200513180058.GB2491@localhost.localdomain> <129070.1589556002@warthog.procyon.org.uk> <20200515152459.GA28995@lst.de> In-Reply-To: <20200515152459.GA28995@lst.de> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.202.205.107] MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: aculab.com X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200516_082120_685258_BFC5BD84 X-CRM114-Status: GOOD ( 20.24 ) X-BeenThere: linux-nvme@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Marcelo Ricardo Leitner , "linux-nvme@lists.infradead.org" , "linux-kernel@vger.kernel.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" , Jakub Kicinski , "linux-block@vger.kernel.org" , Alexey Kuznetsov , "ceph-devel@vger.kernel.org" , "linux-nfs@vger.kernel.org" , Neil Horman , Hideaki YOSHIFUJI , "netdev@vger.kernel.org" , Vlad Yasevich , Eric Dumazet , Jon Maloy , Ying Xue , "David S. Miller" , "ocfs2-devel@oss.oracle.com" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-nvme" Errors-To: linux-nvme-bounces+linux-nvme=archiver.kernel.org@lists.infradead.org From: Christoph Hellwig > Sent: 15 May 2020 16:25 > On Fri, May 15, 2020 at 04:20:02PM +0100, David Howells wrote: > > Christoph Hellwig wrote: > > > > > > 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. > > > > > > True. Not that the intent is to kill kernel space callers of setsockopt, > > > as I plan to remove the set_fs address space override used for it. > > > > For getsockopt, does it make sense to have the core kernel load optval/optlen > > into a buffer before calling the protocol driver? Then the driver need not > > see the userspace pointer at all. > > > > Similar could be done for setsockopt - allocate a buffer of the size requested > > by the user inside the kernel and pass it into the driver, then copy the data > > back afterwards. > > I did look into that initially. The problem is that tons of sockopts > entirely ignore optlen and just use a fixed size. So I fear that there > could be tons of breakage if we suddently respect it. Otherwise that > would be a pretty nice way to handle the situation. I'd guess that most application use the correct size for setsockopt(). (Well, apart from using 4 instead of 1.) It is certainly possible to always try to read in 64 bytes regardless of the supplied length, but handle the EFAULT case by shortening the buffer. Historically getsockopt() only wrote the length back. Treating 0 and garbage as (say) 4k and letting the protocol code set a shorten the copy to user might work. All short transfers would want to use an on-stack buffer, so slight oversizes could also be allowed for. OTOH if i did a getsockopt() with too short a length I wouldn't want the kernel to trash my program memory. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales) _______________________________________________ linux-nvme mailing list linux-nvme@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-nvme