Linux Ethernet Bridging - Jul 2020 - [Bridge] 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?

On Mon, Jul 20, 2020 at 01:47:56PM -0700, Alexei Starovoitov
wrote:
> > 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.
The bpf-next tree is missing all my previous setsockopt cleanups, so
there series won't apply.

On Wed, Jul 22, 2020 at 12:56 AM Christoph Hellwig <hch at lst.de>
wrote:
>
> On Mon, Jul 20, 2020 at 01:47:56PM -0700, Alexei Starovoitov wrote:
> > > 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.
>
> The bpf-next tree is missing all my previous setsockopt cleanups, so
> there series won't apply.
Right. I've realized that after sending that email two days ago.
Now bpf-next->net-next PR is pending and as soon as it's merged
bpf-next will have all the recent bits.