Received-SPF: pass (google.com: domain of linux-kernel+bounces-9546-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Precedence: bulk
MIME-Version: 1.0
References: <20231221154702.2267684-1-guoren@kernel.org> <20231221154702.2267684-3-guoren@kernel.org>
 <367b05acb90d4a6e898dd34e4254b697@AcuMS.aculab.com>
In-Reply-To: <367b05acb90d4a6e898dd34e4254b697@AcuMS.aculab.com>
From: Guo Ren <guoren@kernel.org>
Date: Fri, 22 Dec 2023 17:33:18 +0800
Message-ID: <CAJF2gTRF-e=7kC3bTnQRVLygcagjs5b1+x-8tTb4PkB+XQniKA@mail.gmail.com>
Subject: Re: [PATCH V2 2/4] riscv: mm: Fixup compat arch_get_mmap_end
To: David Laight <David.Laight@aculab.com>
Cc: "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>, 
	"leobras@redhat.com" <leobras@redhat.com>, 
	"linux-riscv@lists.infradead.org" <linux-riscv@lists.infradead.org>, Guo Ren <guoren@linux.alibaba.com>, 
	"stable@vger.kernel.org" <stable@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Dec 22, 2023 at 5:00=E2=80=AFPM David Laight <David.Laight@aculab.c=
om> wrote:
>
> From: guoren@kernel.org <guoren@kernel.org>
> > Sent: 21 December 2023 15:47
> >
> > From: Guo Ren <guoren@linux.alibaba.com>
> >
> > When the task is in COMPAT mode, the arch_get_mmap_end should be 2GB,
> > not TASK_SIZE_64. The TASK_SIZE has contained is_compat_mode()
> > detection, so change the definition of STACK_TOP_MAX to TASK_SIZE
> > directly.
>
> Why 2G ?
>
> IIRC for 32-bit native x86 the limit is 3G, but in compat mode
> it is (just under) 4G.
>
> There is a special mmap option (for programs like wine) to
> limit mmap() to 2G.
The 2G address space seems enough for a small memory scenario, and I
agree the compat mode could support 4G, but it should be another
feature.

We limited our rv32 applications to under 2GB because we want to leave
more address space for the kernel side (Our s64ilp32 kernel needs
vmmap stack, kasan ...).


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


--=20
Best Regards
 Guo Ren