Message-ID: <ab90ff3b-67dc-4195-89a7-54e394da1aa0@lucifer.local>
Date: Thu, 29 Aug 2024 09:42:22 +0100
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Charlie Jenkins <charlie@...osinc.com>
Cc: Arnd Bergmann <arnd@...db.de>,
        Richard Henderson <richard.henderson@...aro.org>,
        Ivan Kokshaysky <ink@...assic.park.msu.ru>,
        Matt Turner <mattst88@...il.com>, Vineet Gupta <vgupta@...nel.org>,
        Russell King <linux@...linux.org.uk>, Guo Ren <guoren@...nel.org>,
        Huacai Chen <chenhuacai@...nel.org>, WANG Xuerui <kernel@...0n.name>,
        Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
        "James E.J. Bottomley" <James.Bottomley@...senpartnership.com>,
        Helge Deller <deller@....de>, Michael Ellerman <mpe@...erman.id.au>,
        Nicholas Piggin <npiggin@...il.com>,
        Christophe Leroy <christophe.leroy@...roup.eu>,
        Naveen N Rao <naveen@...nel.org>,
        Alexander Gordeev <agordeev@...ux.ibm.com>,
        Gerald Schaefer <gerald.schaefer@...ux.ibm.com>,
        Heiko Carstens <hca@...ux.ibm.com>, Vasily Gorbik <gor@...ux.ibm.com>,
        Christian Borntraeger <borntraeger@...ux.ibm.com>,
        Sven Schnelle <svens@...ux.ibm.com>,
        Yoshinori Sato <ysato@...rs.sourceforge.jp>,
        Rich Felker <dalias@...c.org>,
        John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>,
        "David S. Miller" <davem@...emloft.net>,
        Andreas Larsson <andreas@...sler.com>,
        Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
        Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
        "H. Peter Anvin" <hpa@...or.com>, Andy Lutomirski <luto@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Muchun Song <muchun.song@...ux.dev>,
        Andrew Morton <akpm@...ux-foundation.org>,
        "Liam R. Howlett" <Liam.Howlett@...cle.com>,
        Vlastimil Babka <vbabka@...e.cz>, Shuah Khan <shuah@...nel.org>,
        linux-arch@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-alpha@...r.kernel.org, linux-snps-arc@...ts.infradead.org,
        linux-arm-kernel@...ts.infradead.org, linux-csky@...r.kernel.org,
        loongarch@...ts.linux.dev, linux-mips@...r.kernel.org,
        linux-parisc@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org,
        linux-s390@...r.kernel.org, linux-sh@...r.kernel.org,
        sparclinux@...r.kernel.org, linux-mm@...ck.org,
        linux-kselftest@...r.kernel.org
Subject: Re: [PATCH RFC v2 0/4] mm: Introduce MAP_BELOW_HINT

On Thu, Aug 29, 2024 at 12:15:57AM GMT, 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).

I'm still confused as to why, if an mmap flag is desired, and thus programs
are having to be heavily modified and controlled to be able to do this, why
you can't just do an mmap() with PROT_NONE early, around a hinted address
that, sits below the required limit, and then mprotect() or mmap() over it?

Your feature is a major adjustment to mmap(), it needs to be pretty
significantly justified, especially if taking up a new flag.

>
> 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.

You mean x86 _has_ to limit to physically available bits in a canonical
format :) this will not be the case for 5-page table levels though...

>
> Instead of implicitly restricting the address space on riscv (or any
> current/future architecture), a flag would allow users to opt-in to this
> behavior rather than opt-out as is done on other architectures. This is
> desirable because it is a small class of applications that do pointer
> masking.

I raised this last time and you didn't seem to address it so to be more
blunt:

I don't understand why this needs to be an mmap() flag. From this it seems
the whole process needs allocations to be below a certain limit.

That _could_ be achieved through a 'personality' or similar (though a
personality is on/off, rather than allowing configuration so maybe
something else would be needed).

>From what you're saying 57-bit is all you really need right? So maybe
ADDR_LIMIT_57BIT?

I don't see how you're going to actually enforce this in a process either
via an mmap flag, as a library might decide not to use it, so you'd need to
control the allocator, the thread library implementation, and everything
that might allocate.

Liam also raised various points about VMA particulars that I'm not sure are
addressed either.

I just find it hard to believe that everything will fit together.

I'd _really_ need to be convinced that this MAP_ flag is justified, and I"m
just not.

>
> 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.

I'm still very unconvinced and feel the bar needs to be high for making
changes like this that carry maintainership burden.

So for me, it's a no really as an overall concept.

Happy to be convinced otherwise, however... (I may be missing details or
context that provide more justification).

>
> 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@...db.de>
> To: Richard Henderson <richard.henderson@...aro.org>
> To: Ivan Kokshaysky <ink@...assic.park.msu.ru>
> To: Matt Turner <mattst88@...il.com>
> To: Vineet Gupta <vgupta@...nel.org>
> To: Russell King <linux@...linux.org.uk>
> To: Guo Ren <guoren@...nel.org>
> To: Huacai Chen <chenhuacai@...nel.org>
> To: WANG Xuerui <kernel@...0n.name>
> To: Thomas Bogendoerfer <tsbogend@...ha.franken.de>
> To: James E.J. Bottomley <James.Bottomley@...senPartnership.com>
> To: Helge Deller <deller@....de>
> To: Michael Ellerman <mpe@...erman.id.au>
> To: Nicholas Piggin <npiggin@...il.com>
> To: Christophe Leroy <christophe.leroy@...roup.eu>
> To: Naveen N Rao <naveen@...nel.org>
> To: Alexander Gordeev <agordeev@...ux.ibm.com>
> To: Gerald Schaefer <gerald.schaefer@...ux.ibm.com>
> To: Heiko Carstens <hca@...ux.ibm.com>
> To: Vasily Gorbik <gor@...ux.ibm.com>
> To: Christian Borntraeger <borntraeger@...ux.ibm.com>
> To: Sven Schnelle <svens@...ux.ibm.com>
> To: Yoshinori Sato <ysato@...rs.sourceforge.jp>
> To: Rich Felker <dalias@...c.org>
> To: John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>
> To: David S. Miller <davem@...emloft.net>
> To: Andreas Larsson <andreas@...sler.com>
> To: Thomas Gleixner <tglx@...utronix.de>
> To: Ingo Molnar <mingo@...hat.com>
> To: Borislav Petkov <bp@...en8.de>
> To: Dave Hansen <dave.hansen@...ux.intel.com>
> To: x86@...nel.org
> To: H. Peter Anvin <hpa@...or.com>
> To: Andy Lutomirski <luto@...nel.org>
> To: Peter Zijlstra <peterz@...radead.org>
> To: Muchun Song <muchun.song@...ux.dev>
> To: Andrew Morton <akpm@...ux-foundation.org>
> To: Liam R. Howlett <Liam.Howlett@...cle.com>
> To: Vlastimil Babka <vbabka@...e.cz>
> To: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
> To: Shuah Khan <shuah@...nel.org>
> Cc: linux-arch@...r.kernel.org
> Cc: linux-kernel@...r.kernel.org
> Cc: linux-alpha@...r.kernel.org
> Cc: linux-snps-arc@...ts.infradead.org
> Cc: linux-arm-kernel@...ts.infradead.org
> Cc: linux-csky@...r.kernel.org
> Cc: loongarch@...ts.linux.dev
> Cc: linux-mips@...r.kernel.org
> Cc: linux-parisc@...r.kernel.org
> Cc: linuxppc-dev@...ts.ozlabs.org
> Cc: linux-s390@...r.kernel.org
> Cc: linux-sh@...r.kernel.org
> Cc: sparclinux@...r.kernel.org
> Cc: linux-mm@...ck.org
> Cc: linux-kselftest@...r.kernel.org
> Signed-off-by: Charlie Jenkins <charlie@...osinc.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
>
> ---
> Charlie Jenkins (4):
>       mm: Add MAP_BELOW_HINT
>       mm: Add hint and mmap_flags to struct vm_unmapped_area_info
>       mm: Support MAP_BELOW_HINT in vm_unmapped_area()
>       selftests/mm: Create MAP_BELOW_HINT test
>
>  arch/alpha/kernel/osf_sys.c                  |  2 ++
>  arch/arc/mm/mmap.c                           |  3 +++
>  arch/arm/mm/mmap.c                           |  7 ++++++
>  arch/csky/abiv1/mmap.c                       |  3 +++
>  arch/loongarch/mm/mmap.c                     |  3 +++
>  arch/mips/mm/mmap.c                          |  3 +++
>  arch/parisc/kernel/sys_parisc.c              |  3 +++
>  arch/powerpc/mm/book3s64/slice.c             |  7 ++++++
>  arch/s390/mm/hugetlbpage.c                   |  4 ++++
>  arch/s390/mm/mmap.c                          |  6 ++++++
>  arch/sh/mm/mmap.c                            |  6 ++++++
>  arch/sparc/kernel/sys_sparc_32.c             |  3 +++
>  arch/sparc/kernel/sys_sparc_64.c             |  6 ++++++
>  arch/sparc/mm/hugetlbpage.c                  |  4 ++++
>  arch/x86/kernel/sys_x86_64.c                 |  6 ++++++
>  arch/x86/mm/hugetlbpage.c                    |  4 ++++
>  fs/hugetlbfs/inode.c                         |  4 ++++
>  include/linux/mm.h                           |  2 ++
>  include/uapi/asm-generic/mman-common.h       |  1 +
>  mm/mmap.c                                    |  9 ++++++++
>  tools/include/uapi/asm-generic/mman-common.h |  1 +
>  tools/testing/selftests/mm/Makefile          |  1 +
>  tools/testing/selftests/mm/map_below_hint.c  | 32 ++++++++++++++++++++++++++++
>  23 files changed, 120 insertions(+)
> ---
> base-commit: 5be63fc19fcaa4c236b307420483578a56986a37
> change-id: 20240827-patches-below_hint_mmap-b13d79ae1c55
> --
> - Charlie
>

Powered by blists - more mailing lists