| Message ID | 20240905-patches-below_hint_mmap-v3-0-3cd5564efbbb@rivosinc.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | mm: Introduce ADDR_LIMIT_47BIT personality flag | expand |
On Fri, Sep 6, 2024 at 5:16 AM Charlie Jenkins <charlie@rivosinc.com> wrote: > > Some applications rely on placing data in free bits addresses allocated > by mmap. Various architectures (eg. x86, arm64, powerpc) restrict the > address returned by mmap to be less than the 48-bit address space, > unless the hint address uses more than 47 bits (the 48th bit is reserved > for the kernel address space). > > The riscv architecture needs a way to similarly restrict the virtual > address space. On the riscv port of OpenJDK an error is thrown if > attempted to run on the 57-bit address space, called sv57 [1]. golang > has a comment that sv57 support is not complete, but there are some > workarounds to get it to mostly work [2]. > > These applications work on x86 because x86 does an implicit 47-bit > restriction of mmap() address that contain a hint address that is less > than 48 bits. > > Instead of implicitly restricting the address space on riscv (or any > current/future architecture), provide a flag to the personality syscall > that can be used to ensure an application works in any arbitrary VA > space. A similar feature has already been implemented by the personality > syscall in ADDR_LIMIT_32BIT. > > This flag will also allow seemless compatibility between all > architectures, so applications like Go and OpenJDK that use bits in a > virtual address can request the exact number of bits they need in a > generic way. The flag can be checked inside of vm_unmapped_area() so > that this flag does not have to be handled individually by each > architecture. Acked-by: Guo Ren <guoren@kernel.org> Sv57's pain finds its cure in this antidote. > > Link: > https://github.com/openjdk/jdk/blob/f080b4bb8a75284db1b6037f8c00ef3b1ef1add1/src/hotspot/cpu/riscv/vm_version_riscv.cpp#L79 > [1] > Link: > https://github.com/golang/go/blob/9e8ea567c838574a0f14538c0bbbd83c3215aa55/src/runtime/tagptr_64bit.go#L47 > [2] > > To: Arnd Bergmann <arnd@arndb.de> > To: Richard Henderson <richard.henderson@linaro.org> > To: Ivan Kokshaysky <ink@jurassic.park.msu.ru> > To: Matt Turner <mattst88@gmail.com> > To: Vineet Gupta <vgupta@kernel.org> > To: Russell King <linux@armlinux.org.uk> > To: Guo Ren <guoren@kernel.org> > To: Huacai Chen <chenhuacai@kernel.org> > To: WANG Xuerui <kernel@xen0n.name> > To: Thomas Bogendoerfer <tsbogend@alpha.franken.de> > To: James E.J. Bottomley <James.Bottomley@HansenPartnership.com> > To: Helge Deller <deller@gmx.de> > To: Michael Ellerman <mpe@ellerman.id.au> > To: Nicholas Piggin <npiggin@gmail.com> > To: Christophe Leroy <christophe.leroy@csgroup.eu> > To: Naveen N Rao <naveen@kernel.org> > To: Alexander Gordeev <agordeev@linux.ibm.com> > To: Gerald Schaefer <gerald.schaefer@linux.ibm.com> > To: Heiko Carstens <hca@linux.ibm.com> > To: Vasily Gorbik <gor@linux.ibm.com> > To: Christian Borntraeger <borntraeger@linux.ibm.com> > To: Sven Schnelle <svens@linux.ibm.com> > To: Yoshinori Sato <ysato@users.sourceforge.jp> > To: Rich Felker <dalias@libc.org> > To: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> > To: David S. Miller <davem@davemloft.net> > To: Andreas Larsson <andreas@gaisler.com> > To: Thomas Gleixner <tglx@linutronix.de> > To: Ingo Molnar <mingo@redhat.com> > To: Borislav Petkov <bp@alien8.de> > To: Dave Hansen <dave.hansen@linux.intel.com> > To: x86@kernel.org > To: H. Peter Anvin <hpa@zytor.com> > To: Andy Lutomirski <luto@kernel.org> > To: Peter Zijlstra <peterz@infradead.org> > To: Muchun Song <muchun.song@linux.dev> > To: Andrew Morton <akpm@linux-foundation.org> > To: Liam R. Howlett <Liam.Howlett@oracle.com> > To: Vlastimil Babka <vbabka@suse.cz> > To: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> > To: Shuah Khan <shuah@kernel.org> > To: Christoph Hellwig <hch@infradead.org> > To: Michal Hocko <mhocko@suse.com> > To: "Kirill A. Shutemov" <kirill@shutemov.name> > To: Chris Torek <chris.torek@gmail.com> > Cc: linux-arch@vger.kernel.org > Cc: linux-kernel@vger.kernel.org > Cc: linux-alpha@vger.kernel.org > Cc: linux-snps-arc@lists.infradead.org > Cc: linux-arm-kernel@lists.infradead.org > Cc: linux-csky@vger.kernel.org > Cc: loongarch@lists.linux.dev > Cc: linux-mips@vger.kernel.org > Cc: linux-parisc@vger.kernel.org > Cc: linuxppc-dev@lists.ozlabs.org > Cc: linux-s390@vger.kernel.org > Cc: linux-sh@vger.kernel.org > Cc: sparclinux@vger.kernel.org > Cc: linux-mm@kvack.org > Cc: linux-kselftest@vger.kernel.org > Cc: linux-abi-devel@lists.sourceforge.net > Signed-off-by: Charlie Jenkins <charlie@rivosinc.com> > > Changes in v2: > - Added much greater detail to cover letter > - Removed all code that touched architecture specific code and was able > to factor this out into all generic functions, except for flags that > needed to be added to vm_unmapped_area_info > - Made this an RFC since I have only tested it on riscv and x86 > - Link to v1: https://lore.kernel.org/r/20240827-patches-below_hint_mmap-v1-0-46ff2eb9022d@rivosinc.com > > Changes in v3: > - Use a personality flag instead of an mmap flag > - Link to v2: https://lore.kernel.org/r/20240829-patches-below_hint_mmap-v2-0-638a28d9eae0@rivosinc.com > > --- > Charlie Jenkins (2): > mm: Add personality flag to limit address to 47 bits > selftests/mm: Create ADDR_LIMIT_47BIT test > > include/uapi/linux/personality.h | 1 + > mm/mmap.c | 3 ++ > tools/testing/selftests/mm/.gitignore | 1 + > tools/testing/selftests/mm/Makefile | 1 + > tools/testing/selftests/mm/map_47bit_personality.c | 34 ++++++++++++++++++++++ > 5 files changed, 40 insertions(+) > --- > base-commit: 5be63fc19fcaa4c236b307420483578a56986a37 > change-id: 20240827-patches-below_hint_mmap-b13d79ae1c55 > -- > - Charlie >
Hi Charlie, On Thu, 2024-09-05 at 14:15 -0700, Charlie Jenkins wrote: > Some applications rely on placing data in free bits addresses allocated > by mmap. Various architectures (eg. x86, arm64, powerpc) restrict the > address returned by mmap to be less than the 48-bit address space, > unless the hint address uses more than 47 bits (the 48th bit is reserved > for the kernel address space). > > The riscv architecture needs a way to similarly restrict the virtual > address space. On the riscv port of OpenJDK an error is thrown if > attempted to run on the 57-bit address space, called sv57 [1]. golang > has a comment that sv57 support is not complete, but there are some > workarounds to get it to mostly work [2]. > > These applications work on x86 because x86 does an implicit 47-bit > restriction of mmap() address that contain a hint address that is less > than 48 bits. > > Instead of implicitly restricting the address space on riscv (or any > current/future architecture), provide a flag to the personality syscall > that can be used to ensure an application works in any arbitrary VA > space. A similar feature has already been implemented by the personality > syscall in ADDR_LIMIT_32BIT. > > This flag will also allow seemless compatibility between all > architectures, so applications like Go and OpenJDK that use bits in a > virtual address can request the exact number of bits they need in a > generic way. The flag can be checked inside of vm_unmapped_area() so > that this flag does not have to be handled individually by each > architecture. > > Link: > https://github.com/openjdk/jdk/blob/f080b4bb8a75284db1b6037f8c00ef3b1ef1add1/src/hotspot/cpu/riscv/vm_version_riscv.cpp#L79 > [1] > Link: > https://github.com/golang/go/blob/9e8ea567c838574a0f14538c0bbbd83c3215aa55/src/runtime/tagptr_64bit.go#L47 > [2] > > To: Arnd Bergmann <arnd@arndb.de> > To: Richard Henderson <richard.henderson@linaro.org> > To: Ivan Kokshaysky <ink@jurassic.park.msu.ru> > To: Matt Turner <mattst88@gmail.com> > To: Vineet Gupta <vgupta@kernel.org> > To: Russell King <linux@armlinux.org.uk> > To: Guo Ren <guoren@kernel.org> > To: Huacai Chen <chenhuacai@kernel.org> > To: WANG Xuerui <kernel@xen0n.name> > To: Thomas Bogendoerfer <tsbogend@alpha.franken.de> > To: James E.J. Bottomley <James.Bottomley@HansenPartnership.com> > To: Helge Deller <deller@gmx.de> > To: Michael Ellerman <mpe@ellerman.id.au> > To: Nicholas Piggin <npiggin@gmail.com> > To: Christophe Leroy <christophe.leroy@csgroup.eu> > To: Naveen N Rao <naveen@kernel.org> > To: Alexander Gordeev <agordeev@linux.ibm.com> > To: Gerald Schaefer <gerald.schaefer@linux.ibm.com> > To: Heiko Carstens <hca@linux.ibm.com> > To: Vasily Gorbik <gor@linux.ibm.com> > To: Christian Borntraeger <borntraeger@linux.ibm.com> > To: Sven Schnelle <svens@linux.ibm.com> > To: Yoshinori Sato <ysato@users.sourceforge.jp> > To: Rich Felker <dalias@libc.org> > To: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> > To: David S. Miller <davem@davemloft.net> > To: Andreas Larsson <andreas@gaisler.com> > To: Thomas Gleixner <tglx@linutronix.de> > To: Ingo Molnar <mingo@redhat.com> > To: Borislav Petkov <bp@alien8.de> > To: Dave Hansen <dave.hansen@linux.intel.com> > To: x86@kernel.org > To: H. Peter Anvin <hpa@zytor.com> > To: Andy Lutomirski <luto@kernel.org> > To: Peter Zijlstra <peterz@infradead.org> > To: Muchun Song <muchun.song@linux.dev> > To: Andrew Morton <akpm@linux-foundation.org> > To: Liam R. Howlett <Liam.Howlett@oracle.com> > To: Vlastimil Babka <vbabka@suse.cz> > To: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> > To: Shuah Khan <shuah@kernel.org> > To: Christoph Hellwig <hch@infradead.org> > To: Michal Hocko <mhocko@suse.com> > To: "Kirill A. Shutemov" <kirill@shutemov.name> > To: Chris Torek <chris.torek@gmail.com> > Cc: linux-arch@vger.kernel.org > Cc: linux-kernel@vger.kernel.org > Cc: linux-alpha@vger.kernel.org > Cc: linux-snps-arc@lists.infradead.org > Cc: linux-arm-kernel@lists.infradead.org > Cc: linux-csky@vger.kernel.org > Cc: loongarch@lists.linux.dev > Cc: linux-mips@vger.kernel.org > Cc: linux-parisc@vger.kernel.org > Cc: linuxppc-dev@lists.ozlabs.org > Cc: linux-s390@vger.kernel.org > Cc: linux-sh@vger.kernel.org > Cc: sparclinux@vger.kernel.org > Cc: linux-mm@kvack.org > Cc: linux-kselftest@vger.kernel.org > Cc: linux-abi-devel@lists.sourceforge.net > Signed-off-by: Charlie Jenkins <charlie@rivosinc.com> > > Changes in v2: > - Added much greater detail to cover letter > - Removed all code that touched architecture specific code and was able > to factor this out into all generic functions, except for flags that > needed to be added to vm_unmapped_area_info > - Made this an RFC since I have only tested it on riscv and x86 > - Link to v1: https://lore.kernel.org/r/20240827-patches-below_hint_mmap-v1-0-46ff2eb9022d@rivosinc.com > > Changes in v3: > - Use a personality flag instead of an mmap flag > - Link to v2: https://lore.kernel.org/r/20240829-patches-below_hint_mmap-v2-0-638a28d9eae0@rivosinc.com > > --- > Charlie Jenkins (2): > mm: Add personality flag to limit address to 47 bits > selftests/mm: Create ADDR_LIMIT_47BIT test > > include/uapi/linux/personality.h | 1 + > mm/mmap.c | 3 ++ > tools/testing/selftests/mm/.gitignore | 1 + > tools/testing/selftests/mm/Makefile | 1 + > tools/testing/selftests/mm/map_47bit_personality.c | 34 ++++++++++++++++++++++ > 5 files changed, 40 insertions(+) > --- > base-commit: 5be63fc19fcaa4c236b307420483578a56986a37 > change-id: 20240827-patches-below_hint_mmap-b13d79ae1c55 Wow, this issue has been plaguing SPARC users for years already as the architecture uses a 52-bit virtual address space and Javascript engines such as the one in Firefox or Webkit have been crashing ever since. I should definitely give this series a try and see if that fixes Javascript crashes on SPARC. Thanks a lot for addressing this nasty long-standing problem! Adrian
在2024年9月5日九月 下午10:15，Charlie Jenkins写道： > Some applications rely on placing data in free bits addresses allocated > by mmap. Various architectures (eg. x86, arm64, powerpc) restrict the > address returned by mmap to be less than the 48-bit address space, > unless the hint address uses more than 47 bits (the 48th bit is reserved > for the kernel address space). > > The riscv architecture needs a way to similarly restrict the virtual > address space. On the riscv port of OpenJDK an error is thrown if > attempted to run on the 57-bit address space, called sv57 [1]. golang > has a comment that sv57 support is not complete, but there are some > workarounds to get it to mostly work [2]. > > These applications work on x86 because x86 does an implicit 47-bit > restriction of mmap() address that contain a hint address that is less > than 48 bits. > > Instead of implicitly restricting the address space on riscv (or any > current/future architecture), provide a flag to the personality syscall > that can be used to ensure an application works in any arbitrary VA > space. A similar feature has already been implemented by the personality > syscall in ADDR_LIMIT_32BIT. > > This flag will also allow seemless compatibility between all > architectures, so applications like Go and OpenJDK that use bits in a > virtual address can request the exact number of bits they need in a > generic way. The flag can be checked inside of vm_unmapped_area() so > that this flag does not have to be handled individually by each > architecture. Tested-by: Jiaxun Yang <jiaxun.yang@flygoat.com> Tested on MIPS VA 48 system, fixed pointer tagging on mozjs! Thanks! [...]
Some applications rely on placing data in free bits addresses allocated by mmap. Various architectures (eg. x86, arm64, powerpc) restrict the address returned by mmap to be less than the 48-bit address space, unless the hint address uses more than 47 bits (the 48th bit is reserved for the kernel address space). The riscv architecture needs a way to similarly restrict the virtual address space. On the riscv port of OpenJDK an error is thrown if attempted to run on the 57-bit address space, called sv57 [1]. golang has a comment that sv57 support is not complete, but there are some workarounds to get it to mostly work [2]. These applications work on x86 because x86 does an implicit 47-bit restriction of mmap() address that contain a hint address that is less than 48 bits. Instead of implicitly restricting the address space on riscv (or any current/future architecture), provide a flag to the personality syscall that can be used to ensure an application works in any arbitrary VA space. A similar feature has already been implemented by the personality syscall in ADDR_LIMIT_32BIT. This flag will also allow seemless compatibility between all architectures, so applications like Go and OpenJDK that use bits in a virtual address can request the exact number of bits they need in a generic way. The flag can be checked inside of vm_unmapped_area() so that this flag does not have to be handled individually by each architecture. Link: https://github.com/openjdk/jdk/blob/f080b4bb8a75284db1b6037f8c00ef3b1ef1add1/src/hotspot/cpu/riscv/vm_version_riscv.cpp#L79 [1] Link: https://github.com/golang/go/blob/9e8ea567c838574a0f14538c0bbbd83c3215aa55/src/runtime/tagptr_64bit.go#L47 [2] To: Arnd Bergmann <arnd@arndb.de> To: Richard Henderson <richard.henderson@linaro.org> To: Ivan Kokshaysky <ink@jurassic.park.msu.ru> To: Matt Turner <mattst88@gmail.com> To: Vineet Gupta <vgupta@kernel.org> To: Russell King <linux@armlinux.org.uk> To: Guo Ren <guoren@kernel.org> To: Huacai Chen <chenhuacai@kernel.org> To: WANG Xuerui <kernel@xen0n.name> To: Thomas Bogendoerfer <tsbogend@alpha.franken.de> To: James E.J. Bottomley <James.Bottomley@HansenPartnership.com> To: Helge Deller <deller@gmx.de> To: Michael Ellerman <mpe@ellerman.id.au> To: Nicholas Piggin <npiggin@gmail.com> To: Christophe Leroy <christophe.leroy@csgroup.eu> To: Naveen N Rao <naveen@kernel.org> To: Alexander Gordeev <agordeev@linux.ibm.com> To: Gerald Schaefer <gerald.schaefer@linux.ibm.com> To: Heiko Carstens <hca@linux.ibm.com> To: Vasily Gorbik <gor@linux.ibm.com> To: Christian Borntraeger <borntraeger@linux.ibm.com> To: Sven Schnelle <svens@linux.ibm.com> To: Yoshinori Sato <ysato@users.sourceforge.jp> To: Rich Felker <dalias@libc.org> To: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> To: David S. Miller <davem@davemloft.net> To: Andreas Larsson <andreas@gaisler.com> To: Thomas Gleixner <tglx@linutronix.de> To: Ingo Molnar <mingo@redhat.com> To: Borislav Petkov <bp@alien8.de> To: Dave Hansen <dave.hansen@linux.intel.com> To: x86@kernel.org To: H. Peter Anvin <hpa@zytor.com> To: Andy Lutomirski <luto@kernel.org> To: Peter Zijlstra <peterz@infradead.org> To: Muchun Song <muchun.song@linux.dev> To: Andrew Morton <akpm@linux-foundation.org> To: Liam R. Howlett <Liam.Howlett@oracle.com> To: Vlastimil Babka <vbabka@suse.cz> To: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> To: Shuah Khan <shuah@kernel.org> To: Christoph Hellwig <hch@infradead.org> To: Michal Hocko <mhocko@suse.com> To: "Kirill A. Shutemov" <kirill@shutemov.name> To: Chris Torek <chris.torek@gmail.com> Cc: linux-arch@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: linux-alpha@vger.kernel.org Cc: linux-snps-arc@lists.infradead.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-csky@vger.kernel.org Cc: loongarch@lists.linux.dev Cc: linux-mips@vger.kernel.org Cc: linux-parisc@vger.kernel.org Cc: linuxppc-dev@lists.ozlabs.org Cc: linux-s390@vger.kernel.org Cc: linux-sh@vger.kernel.org Cc: sparclinux@vger.kernel.org Cc: linux-mm@kvack.org Cc: linux-kselftest@vger.kernel.org Cc: linux-abi-devel@lists.sourceforge.net Signed-off-by: Charlie Jenkins <charlie@rivosinc.com> Changes in v2: - Added much greater detail to cover letter - Removed all code that touched architecture specific code and was able to factor this out into all generic functions, except for flags that needed to be added to vm_unmapped_area_info - Made this an RFC since I have only tested it on riscv and x86 - Link to v1: https://lore.kernel.org/r/20240827-patches-below_hint_mmap-v1-0-46ff2eb9022d@rivosinc.com Changes in v3: - Use a personality flag instead of an mmap flag - Link to v2: https://lore.kernel.org/r/20240829-patches-below_hint_mmap-v2-0-638a28d9eae0@rivosinc.com --- Charlie Jenkins (2): mm: Add personality flag to limit address to 47 bits selftests/mm: Create ADDR_LIMIT_47BIT test include/uapi/linux/personality.h | 1 + mm/mmap.c | 3 ++ tools/testing/selftests/mm/.gitignore | 1 + tools/testing/selftests/mm/Makefile | 1 + tools/testing/selftests/mm/map_47bit_personality.c | 34 ++++++++++++++++++++++ 5 files changed, 40 insertions(+) --- base-commit: 5be63fc19fcaa4c236b307420483578a56986a37 change-id: 20240827-patches-below_hint_mmap-b13d79ae1c55