From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============4676662491769604445==" MIME-Version: 1.0 From: Alexei Starovoitov To: mptcp at lists.01.org Subject: [MPTCP] Re: get rid of the address_space override in setsockopt Date: Mon, 20 Jul 2020 13:47:56 -0700 Message-ID: <20200720204756.iengwcguikj2yrxt@ast-mbp.dhcp.thefacebook.com> In-Reply-To: 20200720124737.118617-1-hch@lst.de X-Status: X-Keywords: X-UID: 5134 --===============4676662491769604445== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Mon, Jul 20, 2020 at 02:47:13PM +0200, Christoph Hellwig wrote: > Hi Dave, > = > setsockopt is the last place in architecture-independ code that still > uses set_fs to force the uaccess routines to operate on kernel pointers. > = > This series adds a new sockptr_t type that can contained either a kernel > or user pointer, and which has accessors that do the right thing, and > then uses it for setsockopt, starting by refactoring some low-level > helpers and moving them over to it before finally doing the main > setsockopt method. > = > Note that I could not get the eBPF selftests to work, so this has been > tested with a testing patch that always copies the data first and passes > a kernel pointer. This is something that works for most common sockopts > (and is something that the ePBF support relies on), but unfortunately > in various corner cases we either don't use the passed in length, or in > one case actually copy data back from setsockopt, so we unfortunately > can't just always do the copy in the highlevel code, which would have > been much nicer. could you rebase on bpf-next tree and we can route it this way then? we'll also test the whole thing before applying. sounds like v2 is needed anyway to address Eric's addr space concern? --===============4676662491769604445==-- 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=-4.1 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 DF160C433E7 for ; Mon, 20 Jul 2020 20:48:12 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id BC64822BEF for ; Mon, 20 Jul 2020 20:48:12 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="OGmrrLEC" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726812AbgGTUsC (ORCPT ); Mon, 20 Jul 2020 16:48:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58262 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726012AbgGTUsB (ORCPT ); Mon, 20 Jul 2020 16:48:01 -0400 Received: from mail-pj1-x1043.google.com (mail-pj1-x1043.google.com [IPv6:2607:f8b0:4864:20::1043]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A3549C061794; Mon, 20 Jul 2020 13:48:01 -0700 (PDT) Received: by mail-pj1-x1043.google.com with SMTP id md7so536206pjb.1; Mon, 20 Jul 2020 13:48:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=W3gFxb9MTLvTnCe3A+iabUWXBAu7mA9HyhZHWgTOkUw=; b=OGmrrLECo+9bEWcObjspsB7mZd1Knz6TplGXozOrISTfqD7/NX21SXnbWcSkV3fL4v rTtVk5lWAA2Zu7uZ6u1mrfxhancqzyg3QAj3aPjlEycGVWZJlozkhUGEvXA8Lh3Zhd9y MI2pFWCUVAw0qhoczi2fzDR5o+9jsXf0u50JS+cFIfuTYX6fdThXqy7BkTGCK/dg3wkY mbds6x2z1GfwvAA0D5GwOBd9MLDFeCqWgb4tYptazoXAosQDHX7Ytsgw6xoiVQCij+q6 LhYcFToAHR8FWmsf1prWh4sudrDF50FXVoAgPYMNb7eWHKWg9zXFnQitJW8+uw6BZBn8 8EhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=W3gFxb9MTLvTnCe3A+iabUWXBAu7mA9HyhZHWgTOkUw=; b=NmiT+9oS9uGFkHRMP8aKc0bdouhlF+z3N5dmTZmMvJTuQlavya2QOjW9QZluOBDMSN Bf8iOVH8ZwsENeYxwjEQZujdZFojbyI5o/gyN8uqRyJGsRUd4CmnulXJhw4+Gy1N/tQM 4ju/0yxyaquisGWKaNo8IDmPDegmXL1hE7sGBPd37CAuuHg4bE7IRXJLKd5HezY+6rbI 57Abyx0O6OS1c4sJpbqMwZFxec+2L4ngp4CDZv566S1w3ZjoKKvtWYtElQPsITi+GpaX QeoAbDjDDjufLbC3qeDlBil3FMgGdXH7tdt3RJ0ZPfbGcZ8VCfWS6QkfnGtmwRWsDlu/ 2GXQ== X-Gm-Message-State: AOAM532xzswQCE9EmiTk87sBNFqaRV6lXN9+OTa+JTpTX2JXZ3mv7RA8 Lqgsib0ge2mJ4jEvgoQdL6o= X-Google-Smtp-Source: ABdhPJznKJm/ctwfQ0zEUlKph93VMIYlrMPvmwUzvON4KJd0PPoASWmZCQzIIZBDlRvR10ywRtQVEg== X-Received: by 2002:a17:902:a50d:: with SMTP id s13mr19573067plq.149.1595278081037; Mon, 20 Jul 2020 13:48:01 -0700 (PDT) Received: from ast-mbp.dhcp.thefacebook.com ([2620:10d:c090:400::5:e3b]) by smtp.gmail.com with ESMTPSA id m31sm455776pjb.52.2020.07.20.13.47.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 20 Jul 2020 13:47:59 -0700 (PDT) Date: Mon, 20 Jul 2020 13:47:56 -0700 From: Alexei Starovoitov To: Christoph Hellwig Cc: "David S. Miller" , Jakub Kicinski , Alexei Starovoitov , Daniel Borkmann , Alexey Kuznetsov , Hideaki YOSHIFUJI , Eric Dumazet , linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, bpf@vger.kernel.org, netfilter-devel@vger.kernel.org, coreteam@netfilter.org, linux-sctp@vger.kernel.org, linux-hams@vger.kernel.org, linux-bluetooth@vger.kernel.org, bridge@lists.linux-foundation.org, linux-can@vger.kernel.org, dccp@vger.kernel.org, linux-decnet-user@lists.sourceforge.net, linux-wpan@vger.kernel.org, linux-s390@vger.kernel.org, mptcp@lists.01.org, lvs-devel@vger.kernel.org, rds-devel@oss.oracle.com, linux-afs@lists.infradead.org, tipc-discussion@lists.sourceforge.net, linux-x25@vger.kernel.org Subject: Re: get rid of the address_space override in setsockopt Message-ID: <20200720204756.iengwcguikj2yrxt@ast-mbp.dhcp.thefacebook.com> References: <20200720124737.118617-1-hch@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200720124737.118617-1-hch@lst.de> Sender: linux-crypto-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org On Mon, Jul 20, 2020 at 02:47:13PM +0200, Christoph Hellwig wrote: > Hi Dave, > > setsockopt is the last place in architecture-independ code that still > uses set_fs to force the uaccess routines to operate on kernel pointers. > > This series adds a new sockptr_t type that can contained either a kernel > or user pointer, and which has accessors that do the right thing, and > then uses it for setsockopt, starting by refactoring some low-level > helpers and moving them over to it before finally doing the main > setsockopt method. > > Note that I could not get the eBPF selftests to work, so this has been > tested with a testing patch that always copies the data first and passes > a kernel pointer. This is something that works for most common sockopts > (and is something that the ePBF support relies on), but unfortunately > in various corner cases we either don't use the passed in length, or in > one case actually copy data back from setsockopt, so we unfortunately > can't just always do the copy in the highlevel code, which would have > been much nicer. could you rebase on bpf-next tree and we can route it this way then? we'll also test the whole thing before applying. sounds like v2 is needed anyway to address Eric's addr space concern? From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexei Starovoitov Subject: Re: get rid of the address_space override in setsockopt Date: Mon, 20 Jul 2020 13:47:56 -0700 Message-ID: <20200720204756.iengwcguikj2yrxt@ast-mbp.dhcp.thefacebook.com> References: <20200720124737.118617-1-hch@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <20200720124737.118617-1-hch-jcswGhMUV9g@public.gmane.org> Sender: linux-bluetooth-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Christoph Hellwig Cc: "David S. Miller" , Jakub Kicinski , Alexei Starovoitov , Daniel Borkmann , Alexey Kuznetsov , Hideaki YOSHIFUJI , Eric Dumazet , linux-crypto-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, bpf-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, netfilter-devel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, coreteam-Cap9r6Oaw4JrovVCs/uTlw@public.gmane.org, linux-sctp-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-hams-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-bluetooth-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, bridge-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, linux-can-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, dccp-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-decnet-user-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org, linux-wpan-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-s390-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, mptcp-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org, lvs-devel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, rds-devel@oss.o List-Id: linux-can.vger.kernel.org On Mon, Jul 20, 2020 at 02:47:13PM +0200, Christoph Hellwig wrote: > Hi Dave, > > setsockopt is the last place in architecture-independ code that still > uses set_fs to force the uaccess routines to operate on kernel pointers. > > This series adds a new sockptr_t type that can contained either a kernel > or user pointer, and which has accessors that do the right thing, and > then uses it for setsockopt, starting by refactoring some low-level > helpers and moving them over to it before finally doing the main > setsockopt method. > > Note that I could not get the eBPF selftests to work, so this has been > tested with a testing patch that always copies the data first and passes > a kernel pointer. This is something that works for most common sockopts > (and is something that the ePBF support relies on), but unfortunately > in various corner cases we either don't use the passed in length, or in > one case actually copy data back from setsockopt, so we unfortunately > can't just always do the copy in the highlevel code, which would have > been much nicer. could you rebase on bpf-next tree and we can route it this way then? we'll also test the whole thing before applying. sounds like v2 is needed anyway to address Eric's addr space concern? From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexei Starovoitov Date: Mon, 20 Jul 2020 20:47:56 +0000 Subject: Re: get rid of the address_space override in setsockopt Message-Id: <20200720204756.iengwcguikj2yrxt@ast-mbp.dhcp.thefacebook.com> List-Id: References: <20200720124737.118617-1-hch@lst.de> In-Reply-To: <20200720124737.118617-1-hch@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Christoph Hellwig Cc: "David S. Miller" , Jakub Kicinski , Alexei Starovoitov , Daniel Borkmann , Alexey Kuznetsov , Hideaki YOSHIFUJI , Eric Dumazet , linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, bpf@vger.kernel.org, netfilter-devel@vger.kernel.org, coreteam@netfilter.org, linux-sctp@vger.kernel.org, linux-hams@vger.kernel.org, linux-bluetooth@vger.kernel.org, bridge@lists.linux-foundation.org, linux-can@vger.kernel.org, dccp@vger.kernel.org, linux-decnet-user@lists.sourceforge.net, linux-wpan@vger.kernel.org, linux-s390@vger.kernel.org, mptcp@lists.01.org, lvs-devel@vger.kernel.org, rds-devel@oss.oracle.com, linux-afs@lists.infradead.org, tipc-discussion@lists.sourceforge.net, linux-x25@vger.kernel.org On Mon, Jul 20, 2020 at 02:47:13PM +0200, Christoph Hellwig wrote: > Hi Dave, > > setsockopt is the last place in architecture-independ code that still > uses set_fs to force the uaccess routines to operate on kernel pointers. > > This series adds a new sockptr_t type that can contained either a kernel > or user pointer, and which has accessors that do the right thing, and > then uses it for setsockopt, starting by refactoring some low-level > helpers and moving them over to it before finally doing the main > setsockopt method. > > Note that I could not get the eBPF selftests to work, so this has been > tested with a testing patch that always copies the data first and passes > a kernel pointer. This is something that works for most common sockopts > (and is something that the ePBF support relies on), but unfortunately > in various corner cases we either don't use the passed in length, or in > one case actually copy data back from setsockopt, so we unfortunately > can't just always do the copy in the highlevel code, which would have > been much nicer. could you rebase on bpf-next tree and we can route it this way then? we'll also test the whole thing before applying. sounds like v2 is needed anyway to address Eric's addr space concern? From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexei Starovoitov Date: Mon, 20 Jul 2020 20:47:56 +0000 Subject: Re: get rid of the address_space override in setsockopt Message-Id: <20200720204756.iengwcguikj2yrxt@ast-mbp.dhcp.thefacebook.com> List-Id: References: <20200720124737.118617-1-hch@lst.de> In-Reply-To: <20200720124737.118617-1-hch@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: dccp@vger.kernel.org On Mon, Jul 20, 2020 at 02:47:13PM +0200, Christoph Hellwig wrote: > Hi Dave, > > setsockopt is the last place in architecture-independ code that still > uses set_fs to force the uaccess routines to operate on kernel pointers. > > This series adds a new sockptr_t type that can contained either a kernel > or user pointer, and which has accessors that do the right thing, and > then uses it for setsockopt, starting by refactoring some low-level > helpers and moving them over to it before finally doing the main > setsockopt method. > > Note that I could not get the eBPF selftests to work, so this has been > tested with a testing patch that always copies the data first and passes > a kernel pointer. This is something that works for most common sockopts > (and is something that the ePBF support relies on), but unfortunately > in various corner cases we either don't use the passed in length, or in > one case actually copy data back from setsockopt, so we unfortunately > can't just always do the copy in the highlevel code, which would have > been much nicer. could you rebase on bpf-next tree and we can route it this way then? we'll also test the whole thing before applying. sounds like v2 is needed anyway to address Eric's addr space concern? From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=W3gFxb9MTLvTnCe3A+iabUWXBAu7mA9HyhZHWgTOkUw=; b=OGmrrLECo+9bEWcObjspsB7mZd1Knz6TplGXozOrISTfqD7/NX21SXnbWcSkV3fL4v rTtVk5lWAA2Zu7uZ6u1mrfxhancqzyg3QAj3aPjlEycGVWZJlozkhUGEvXA8Lh3Zhd9y MI2pFWCUVAw0qhoczi2fzDR5o+9jsXf0u50JS+cFIfuTYX6fdThXqy7BkTGCK/dg3wkY mbds6x2z1GfwvAA0D5GwOBd9MLDFeCqWgb4tYptazoXAosQDHX7Ytsgw6xoiVQCij+q6 LhYcFToAHR8FWmsf1prWh4sudrDF50FXVoAgPYMNb7eWHKWg9zXFnQitJW8+uw6BZBn8 8EhQ== Date: Mon, 20 Jul 2020 13:47:56 -0700 From: Alexei Starovoitov Message-ID: <20200720204756.iengwcguikj2yrxt@ast-mbp.dhcp.thefacebook.com> References: <20200720124737.118617-1-hch@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200720124737.118617-1-hch@lst.de> Subject: Re: [Bridge] get rid of the address_space override in setsockopt List-Id: Linux Ethernet Bridging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Christoph Hellwig Cc: Alexei Starovoitov , linux-sctp@vger.kernel.org, linux-afs@lists.infradead.org, linux-s390@vger.kernel.org, rds-devel@oss.oracle.com, Daniel Borkmann , dccp@vger.kernel.org, bridge@lists.linux-foundation.org, lvs-devel@vger.kernel.org, coreteam@netfilter.org, mptcp@lists.01.org, Alexey Kuznetsov , linux-can@vger.kernel.org, Jakub Kicinski , linux-hams@vger.kernel.org, tipc-discussion@lists.sourceforge.net, linux-x25@vger.kernel.org, Eric Dumazet , Hideaki YOSHIFUJI , netdev@vger.kernel.org, linux-decnet-user@lists.sourceforge.net, linux-kernel@vger.kernel.org, linux-bluetooth@vger.kernel.org, netfilter-devel@vger.kernel.org, linux-crypto@vger.kernel.org, bpf@vger.kernel.org, linux-wpan@vger.kernel.org, "David S. Miller" On Mon, Jul 20, 2020 at 02:47:13PM +0200, Christoph Hellwig wrote: > Hi Dave, > > setsockopt is the last place in architecture-independ code that still > uses set_fs to force the uaccess routines to operate on kernel pointers. > > This series adds a new sockptr_t type that can contained either a kernel > or user pointer, and which has accessors that do the right thing, and > then uses it for setsockopt, starting by refactoring some low-level > helpers and moving them over to it before finally doing the main > setsockopt method. > > Note that I could not get the eBPF selftests to work, so this has been > tested with a testing patch that always copies the data first and passes > a kernel pointer. This is something that works for most common sockopts > (and is something that the ePBF support relies on), but unfortunately > in various corner cases we either don't use the passed in length, or in > one case actually copy data back from setsockopt, so we unfortunately > can't just always do the copy in the highlevel code, which would have > been much nicer. could you rebase on bpf-next tree and we can route it this way then? we'll also test the whole thing before applying. sounds like v2 is needed anyway to address Eric's addr space concern?