RE: [PATCH V2 4/4] riscv: mm: Optimize TASK_SIZE definition

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

From: Guo Ren
> Sent: 23 December 2023 02:53
> 
> On Fri, Dec 22, 2023 at 7:52 PM David Laight <David.Laight@aculab.com> wrote:
> >
> > From: Guo Ren
> > > Sent: 22 December 2023 11:25
> > ...
> > > > > +#define TASK_SIZE    (is_compat_task() ? \
> > > > >                        TASK_SIZE_32 : TASK_SIZE_64)
> > > I would remove is_compat_task() in the next version because your patch
> > > contains that.
> >
> > Does TASK_SIZE get used in access_ok() ?
> > If so the repeated expansion of that 'mess' will slow things down.
> >
> > OTOH access_ok(ptr, len) can just check (ptr | (ptr + len)) < 0)
> > and rely on the page faults for everything else.
> Or do you want to discuss the bad side effect of is_compat_task()?
> 
> Yes, test_thread_flag(TIF_32BIT) would slow down access_ok(). But if
> we use TASK_SIZE_MAX, VA_BITS still needs pgtable_l5_enabled,
> pgtable_l4_enabled detectation for riscv.
> 
> It's not only for compat mode, but also Sv39, Sv48, Sv57. All treat
> TASK_SIZE_MAX as 0x8000000000000000, right? Then:
> access_ok(ptr, len) can just check (ptr | (ptr + len)) < 0)
> 
> It's another feature and does not relate to compat mode.

Compat mode just makes it worse...

One possibility would be to save the task's max user address
in the task structure itself - that would save all the conditionals
at a cost of an extra value in the task structure.

There is also the question of whether a normally 64-bit task
can actually make the compat mmap() system call?
On x86 that is certainly possible (IIRC wine does it), x86
userspace can flip between 32bit and 63bit mode without a
system call.

	David

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