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

From: David Laight <David.Laight@ACULAB.COM>
To: 'Alexandre Ghiti' <alex@ghiti.fr>,
	Samuel Holland <samuel.holland@sifive.com>,
	Alexandre Ghiti <alexghiti@rivosinc.com>
Cc: Palmer Dabbelt <palmer@dabbelt.com>,
	"linux-riscv@lists.infradead.org"
	<linux-riscv@lists.infradead.org>,
	Albert Ou <aou@eecs.berkeley.edu>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	Charlie Jenkins <charlie@rivosinc.com>,
	Guo Ren <guoren@kernel.org>, Jisheng Zhang <jszhang@kernel.org>,
	Kemeng Shi <shikemeng@huaweicloud.com>,
	"Matthew Wilcox (Oracle)" <willy@infradead.org>,
	"Mike Rapoport (IBM)" <rppt@kernel.org>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Xiao Wang <xiao.w.wang@intel.com>, Yangyu Chen <cyy@cyyself.name>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH] riscv: Define TASK_SIZE_MAX for __access_ok()
Date: Sun, 24 Mar 2024 19:42:01 +0000	[thread overview]
Message-ID: <f786e02245424e02b38f55ae6b29d14a@AcuMS.aculab.com> (raw)
In-Reply-To: <b5624bba-9917-421b-8ef0-4515d442f80b@ghiti.fr>

...
> 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.

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@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv