Received-SPF: pass (google.com: domain of linux-kernel+bounces-10619-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Precedence: bulk
MIME-Version: 1.0
References: <20231221154702.2267684-1-guoren@kernel.org> <20231221154702.2267684-5-guoren@kernel.org>
 <ZYUZ8QUJxCL93Fgv@LeoBras> <CAJF2gTTX7AjexoRUw=ZS34HEWno7H3zvnXA+Q7TYsztNU=k2cg@mail.gmail.com>
 <e3f1521a9f04463587d07d0c99534d5a@AcuMS.aculab.com> <CAJF2gTRD827Fbs_2FxBP=Z8yudfAAqG6dA+a9eq74RMOz2WDnw@mail.gmail.com>
 <9d4d15e8e3e944b8bd18e8bc1d54f59c@AcuMS.aculab.com>
In-Reply-To: <9d4d15e8e3e944b8bd18e8bc1d54f59c@AcuMS.aculab.com>
From: Guo Ren <guoren@kernel.org>
Date: Sun, 24 Dec 2023 09:24:00 +0800
Message-ID: <CAJF2gTQjixePmc8qNJZB+kfyzjVb+NqFHR6GOow-aNhN883CQA@mail.gmail.com>
Subject: Re: [PATCH V2 4/4] riscv: mm: Optimize TASK_SIZE definition
To: David Laight <David.Laight@aculab.com>
Cc: Leonardo Bras <leobras@redhat.com>, 
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, 
	"paul.walmsley@sifive.com" <paul.walmsley@sifive.com>, "palmer@dabbelt.com" <palmer@dabbelt.com>, 
	"alexghiti@rivosinc.com" <alexghiti@rivosinc.com>, "charlie@rivosinc.com" <charlie@rivosinc.com>, 
	"xiao.w.wang@intel.com" <xiao.w.wang@intel.com>, "david@redhat.com" <david@redhat.com>, 
	"panqinglin2020@iscas.ac.cn" <panqinglin2020@iscas.ac.cn>, 
	"rick.p.edgecombe@intel.com" <rick.p.edgecombe@intel.com>, "willy@infradead.org" <willy@infradead.org>, 
	"bjorn@rivosinc.com" <bjorn@rivosinc.com>, 
	"conor.dooley@microchip.com" <conor.dooley@microchip.com>, "cleger@rivosinc.com" <cleger@rivosinc.com>, 
	"linux-riscv@lists.infradead.org" <linux-riscv@lists.infradead.org>, Guo Ren <guoren@linux.alibaba.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, Dec 23, 2023 at 6:31=E2=80=AFPM David Laight <David.Laight@aculab.c=
om> wrote:
>
> From: Guo Ren
> > Sent: 23 December 2023 02:53
> >
> > On Fri, Dec 22, 2023 at 7:52=E2=80=AFPM David Laight <David.Laight@acul=
ab.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 pa=
tch
> > > > 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...
It's hard to observe.

>
> 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.
It would still cause memory load operation, although it is $tp->xxx.
If we want to gain observability benefits, "just check (ptr | (ptr +
len)) < 0)" is better.

>
> There is also the question of whether a normally 64-bit task
> can actually make the compat mmap() system call?
No.

> On x86 that is certainly possible (IIRC wine does it), x86
> userspace can flip between 32bit and 63bit mode without a
> system call.
RISC-V can't do that because it needs sstatux.uxl=3D32/64, which can
only be modified in S-mode.


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


--=20
Best Regards
 Guo Ren