[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <935d551809894d14965e430e05d21057@AcuMS.aculab.com>
Date: Mon, 17 Aug 2020 08:23:11 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Christoph Hellwig' <hch@....de>,
Al Viro <viro@...iv.linux.org.uk>,
Michael Ellerman <mpe@...erman.id.au>,
"x86@...nel.org" <x86@...nel.org>
CC: Kees Cook <keescook@...omium.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
"linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
"linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>
Subject: RE: [PATCH 09/11] x86: remove address space overrides using set_fs()
From: Christoph Hellwig
> Sent: 17 August 2020 08:32
>
> Stop providing the possibility to override the address space using
> set_fs() now that there is no need for that any more. To properly
> handle the TASK_SIZE_MAX checking for 4 vs 5-level page tables on
> x86 a new alternative is introduced, which just like the one in
> entry_64.S has to use the hardcoded virtual address bits to escape
> the fact that TASK_SIZE_MAX isn't actually a constant when 5-level
> page tables are enabled.
....
> @@ -93,7 +69,7 @@ static inline bool pagefault_disabled(void);
> #define access_ok(addr, size) \
> ({ \
> WARN_ON_IN_IRQ(); \
> - likely(!__range_not_ok(addr, size, user_addr_max())); \
> + likely(!__range_not_ok(addr, size, TASK_SIZE_MAX)); \
> })
Can't that always compare against a constant even when 5-levl
page tables are enabled on x86-64?
On x86-64 it can (probably) reduce to (addr | (addr + size)) < 0.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Powered by blists - more mailing lists