Re: [PATCH v6 14/14] riscv: Make mmap allocation top-down by default

From: Alex Ghiti
Date: Tue Oct 08 2019 - 05:19:29 EST


On 10/7/19 5:11 AM, Alex Ghiti wrote:
On 10/4/19 10:12 PM, Atish Patra wrote:
On Thu, 2019-08-08 at 02:17 -0400, Alexandre Ghiti wrote:
In order to avoid wasting user address space by using bottom-up mmap
allocation scheme, prefer top-down scheme when possible.

Before:
root@qemuriscv64:~# cat /proc/self/maps
00010000-00016000 r-xp 00000000 fe:00 6389 /bin/cat.coreutils
00016000-00017000 r--p 00005000 fe:00 6389 /bin/cat.coreutils
00017000-00018000 rw-p 00006000 fe:00 6389 /bin/cat.coreutils
00018000-00039000 rw-p 00000000 00:00 0ÂÂÂÂÂÂÂÂÂ [heap]
1555556000-155556d000 r-xp 00000000 fe:00 7193 /lib/ld-2.28.so
155556d000-155556e000 r--p 00016000 fe:00 7193 /lib/ld-2.28.so
155556e000-155556f000 rw-p 00017000 fe:00 7193 /lib/ld-2.28.so
155556f000-1555570000 rw-p 00000000 00:00 0
1555570000-1555572000 r-xp 00000000 00:00 0ÂÂÂÂÂ [vdso]
1555574000-1555576000 rw-p 00000000 00:00 0
1555576000-1555674000 r-xp 00000000 fe:00 7187 /lib/libc-2.28.so
1555674000-1555678000 r--p 000fd000 fe:00 7187 /lib/libc-2.28.so
1555678000-155567a000 rw-p 00101000 fe:00 7187 /lib/libc-2.28.so
155567a000-15556a0000 rw-p 00000000 00:00 0
3fffb90000-3fffbb1000 rw-p 00000000 00:00 0ÂÂÂÂÂ [stack]

After:
root@qemuriscv64:~# cat /proc/self/maps
00010000-00016000 r-xp 00000000 fe:00 6389 /bin/cat.coreutils
00016000-00017000 r--p 00005000 fe:00 6389 /bin/cat.coreutils
00017000-00018000 rw-p 00006000 fe:00 6389 /bin/cat.coreutils
2de81000-2dea2000 rw-p 00000000 00:00 0ÂÂÂÂÂÂÂÂÂ [heap]
3ff7eb6000-3ff7ed8000 rw-p 00000000 00:00 0
3ff7ed8000-3ff7fd6000 r-xp 00000000 fe:00 7187 /lib/libc-2.28.so
3ff7fd6000-3ff7fda000 r--p 000fd000 fe:00 7187 /lib/libc-2.28.so
3ff7fda000-3ff7fdc000 rw-p 00101000 fe:00 7187 /lib/libc-2.28.so
3ff7fdc000-3ff7fe2000 rw-p 00000000 00:00 0
3ff7fe4000-3ff7fe6000 r-xp 00000000 00:00 0ÂÂÂÂÂ [vdso]
3ff7fe6000-3ff7ffd000 r-xp 00000000 fe:00 7193 /lib/ld-2.28.so
3ff7ffd000-3ff7ffe000 r--p 00016000 fe:00 7193 /lib/ld-2.28.so
3ff7ffe000-3ff7fff000 rw-p 00017000 fe:00 7193 /lib/ld-2.28.so
3ff7fff000-3ff8000000 rw-p 00000000 00:00 0
3fff888000-3fff8a9000 rw-p 00000000 00:00 0ÂÂÂÂÂ [stack]

Signed-off-by: Alexandre Ghiti <alex@xxxxxxxx>
Acked-by: Paul Walmsley <paul.walmsley@xxxxxxxxxx>
Reviewed-by: Christoph Hellwig <hch@xxxxxx>
Reviewed-by: Kees Cook <keescook@xxxxxxxxxxxx>
Reviewed-by: Luis Chamberlain <mcgrof@xxxxxxxxxx>
---
 arch/riscv/Kconfig | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 59a4727ecd6c..87dc5370becb 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -54,6 +54,18 @@ config RISCV
ÂÂÂÂÂ select EDAC_SUPPORT
ÂÂÂÂÂ select ARCH_HAS_GIGANTIC_PAGE
ÂÂÂÂÂ select ARCH_WANT_HUGE_PMD_SHARE if 64BIT
+ÂÂÂ select ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT if MMU
+ÂÂÂ select HAVE_ARCH_MMAP_RND_BITS
+
+config ARCH_MMAP_RND_BITS_MIN
+ÂÂÂ default 18 if 64BIT
+ÂÂÂ default 8
+
+# max bits determined by the following formula:
+#Â VA_BITS - PAGE_SHIFT - 3
+config ARCH_MMAP_RND_BITS_MAX
+ÂÂÂ default 24 if 64BIT # SV39 based
+ÂÂÂ default 17
  config MMU
ÂÂÂÂÂ def_bool y
With this patch, I am not able to boot a Fedora Linux(a Gnome desktop
image) on RISC-V hardware (Unleashed + Microsemi Expansion board). The
booting gets stuck right after systemd starts.

https://paste.fedoraproject.org/paste/TOrUMqqKH-pGFX7CnfajDg

Reverting just this patch allow to boot Fedora successfully on specific
RISC-V hardware. I have not root caused the issue but it looks like it
might have messed userpsace mapping.

It might have messed userspace mapping but not enough to make userspace completely broken
as systemd does some things. I would try to boot in legacy layout: if you can try to set sysctl legacy_va_layout
at boottime, it will map userspace as it was before (bottom-up). If that does not work, the problem could
be the randomization that is activated by default now.
Anyway, it's weird since userspace should not depend on how the mapping is.

If you can identify the program that stalls, that would be fantastic :)

As the code is common to mips and arm now and I did not hear from them, I imagine the problem comes
from us.

Alex

Atish, do you have any news regarding this problem ? If you have an image I can execute on qemu that
reproduces the issue, I can take a look.

Alex