RE: [PATCH] riscv: Define TASK_SIZE_MAX for __access_ok()

[David Laight]

From: Alexandre Ghiti
> Sent: 25 March 2024 07:31
> 
> Hi David,
> 
> On 24/03/2024 20:42, David Laight wrote:
> > ...
> >> The use of alternatives allows to return right away if the buffer is
> >> beyond the usable user address space, and it's not just "slightly
> >> faster" for some cases (a very large buffer with only a few bytes being
> >> beyond the limit or someone could fault-in all the user pages and fail
> >> very late...etc). access_ok() is here to guarantee that such situations
> >> don't happen, so actually it makes more sense to use an alternative to
> >> avoid that.
> >
> > Is it really worth doing ANY optimisations for the -EFAULT path?
> > They really don't happen.
> >
> > The only fault path that matters is the one that has to page in
> > data from somewhere.
> 
> 
> Which is completely avoided with a strict definition of access_ok(). I
> see access_ok() as an already existing optimization of fault paths by
> avoiding them entirely when they are bound to happen.

No, access_ok() exists because accesses to kernel addresses don't fault.
Possibly in linux 0.01 it tried to ensure that the access was valid
(by checking the process's page tables (etc) but that that hasn't been
true for a long time.

You don't want to add a single instruction (never mind a conditional)
to access_ok() to avoid a page fault on an address that will fault.

Basically real programs don't pass bad addresses into the kernel
or access them in userspace. EFAULT and SIGSEGV are pretty fatal.
(Nothing call sbrk() from its SIGSEGV handler any more!)

	David

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