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=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 6D235C433E0 for ; Thu, 14 May 2020 08:29:37 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4DDDF20675 for ; Thu, 14 May 2020 08:29:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726108AbgENI3g convert rfc822-to-8bit (ORCPT ); Thu, 14 May 2020 04:29:36 -0400 Received: from eu-smtp-delivery-151.mimecast.com ([185.58.86.151]:30013 "EHLO eu-smtp-delivery-151.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726037AbgENI3g (ORCPT ); Thu, 14 May 2020 04:29:36 -0400 Received: from AcuMS.aculab.com (156.67.243.126 [156.67.243.126]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-41-3XJ_vbSSOB-Mdnc0632Mfw-1; Thu, 14 May 2020 09:29:32 +0100 X-MC-Unique: 3XJ_vbSSOB-Mdnc0632Mfw-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; Thu, 14 May 2020 09:29:31 +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; Thu, 14 May 2020 09:29:31 +0100 From: David Laight To: 'Joe Perches' , Christoph Hellwig , "David S. Miller" , Jakub Kicinski CC: Eric Dumazet , Alexey Kuznetsov , Hideaki YOSHIFUJI , "Vlad Yasevich" , Neil Horman , "Marcelo Ricardo Leitner" , 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: RE: remove kernel_setsockopt and kernel_getsockopt Thread-Topic: remove kernel_setsockopt and kernel_getsockopt Thread-Index: AQHWKU15LJmP4mOGDE2/GHhLszFt9KinP7aQ Date: Thu, 14 May 2020 08:29:30 +0000 Message-ID: <756758e8f0e34e2e97db470609f5fbba@AcuMS.aculab.com> References: <20200513062649.2100053-1-hch@lst.de> In-Reply-To: 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 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Joe Perches > Sent: 13 May 2020 18:39 > On Wed, 2020-05-13 at 08:26 +0200, Christoph Hellwig wrote: > > this series removes the kernel_setsockopt and kernel_getsockopt > > functions, and instead switches their users to small functions that > > implement setting (or in one case getting) a sockopt directly using > > a normal kernel function call with type safety and all the other > > benefits of not having a function call. > > > > In some cases these functions seem pretty heavy handed as they do > > a lock_sock even for just setting a single variable, but this mirrors > > the real setsockopt implementation - counter to that a few kernel > > drivers just set the fields directly already. > > > > Nevertheless the diffstat looks quite promising: > > > > 42 files changed, 721 insertions(+), 799 deletions(-) I missed this patch going through. Massive NACK. You need to export functions that do most of the socket options for all protocols. As well as REUSADDR and NODELAY SCTP has loads because a lot of stuff that should have been extra system calls got piled into setsockopt. An alternate solution would be to move the copy_to/from_user() into a wrapper function so that the kernel_[sg]etsockopt() functions would bypass them completely. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)