[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200720204756.iengwcguikj2yrxt@ast-mbp.dhcp.thefacebook.com>
Date: Mon, 20 Jul 2020 13:47:56 -0700
From: Alexei Starovoitov <alexei.starovoitov@...il.com>
To: Christoph Hellwig <hch@....de>
Cc: "David S. Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>,
Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>,
Alexey Kuznetsov <kuznet@....inr.ac.ru>,
Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
Eric Dumazet <edumazet@...gle.com>,
linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org,
netdev@...r.kernel.org, bpf@...r.kernel.org,
netfilter-devel@...r.kernel.org, coreteam@...filter.org,
linux-sctp@...r.kernel.org, linux-hams@...r.kernel.org,
linux-bluetooth@...r.kernel.org, bridge@...ts.linux-foundation.org,
linux-can@...r.kernel.org, dccp@...r.kernel.org,
linux-decnet-user@...ts.sourceforge.net,
linux-wpan@...r.kernel.org, linux-s390@...r.kernel.org,
mptcp@...ts.01.org, lvs-devel@...r.kernel.org,
rds-devel@....oracle.com, linux-afs@...ts.infradead.org,
tipc-discussion@...ts.sourceforge.net, linux-x25@...r.kernel.org
Subject: Re: get rid of the address_space override in setsockopt
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?
Powered by blists - more mailing lists