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

[Alexandre Ghiti]

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.

Thanks,

Alex


> Provided there is a gap between the highest valid user address and the
> lowest valid kernel address (may not be true on some 32bit systems)
> and copy_to/from_user() do 'increasing address' copies then the
> access_ok() check they do can almost certainly ignore the length.
>
> This may be true for pretty much all access_ok() tests?
> It would certainly simplify the test.
>
> 	David
>
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
> Registration No: 1397386 (Wales)
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@xxxxxxxxxxxxxxxxxxx
> http://lists.infradead.org/mailman/listinfo/linux-riscv