RE: [PATCH 03/11] fs: add new read_uptr and write_uptr file operations

[David Laight <David.Laight@ACULAB.COM>]

From: Linus Torvalds
> Sent: 24 June 2020 19:12
> On Wed, Jun 24, 2020 at 10:55 AM Christoph Hellwig <hch@lst.de> wrote:
> >
> > I don't care at all.  Based on our previous chat I assumed you
> > wanted something like this.  We might still need the uptr_t for
> > setsockopt, though.
> 
> No.
> 
> What I mean was *not* something like uptr_t.
> 
> Just keep the existing "set_fs()". It's not harmful if it's only used
> occasionally. We should rename it once it's rare enough, though.

Am I right in thinking that it just sets a flag in 'current' ?
Although I don't remember access_ok() doing a suitable check
(would need to be (address - base) < limit).

> Then, make the following changes:
> 
>  - all the normal user access functions stop caring. They use
> TASK_SIZE_MAX and are done with it. They basically stop reacting to
> set_fs().
> 
>  - then, we can have a few *very* specific cases (like setsockopt,
> maybe some random read/write) that we teach to use the new set_fs()
> thing.

Certainly there is a 'BPF' hook in the setsockopt() syscall handler
that can substitute a kernel buffer for any setsockopt() request.

If that is needed (I presume it was added for a purpose) then all
the socket option code needs to be able to handle kernel buffers.
(Actually given what some getsockopt() do, if there was a
requirement to 'adjust' setsockopt() then there should be a hook
in the getsockopt() code as well.)

If you are going to go through all the socket option code to change
the name of all the buffer access functions then it is probably
almost as easy to move the usercopies out into the wrappers.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)