Re: [PATCH v6 14/14] riscv: Make mmap allocation top-down by default
On Okt 15 2019, Atish Patra wrote: > Nope. This is only reproducible in RISC-V Fedora Gnome desktop image on > a HiFive Unleashed + Microsemi Expansion. Just to clarify, there is no > issue with OpenEmbedded disk image related to memory layout. It was a > userspace thing. Does it also happen with any of the openSUSE images? https://download.opensuse.org/ports/riscv/tumbleweed/images/ Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
Re: [PATCH v6 14/14] riscv: Make mmap allocation top-down by default
On Wed, 2019-10-09 at 14:39 -0400, Alex Ghiti wrote: > On 10/8/19 10:07 PM, Atish Patra wrote: > > On Tue, 2019-10-08 at 07:58 -0400, Alex Ghiti wrote: > > > On 10/7/19 8:46 PM, Atish Patra wrote: > > > > On Mon, 2019-10-07 at 05:11 -0400, 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 > > > > > > > 0001-00016000 r-xp fe:00 > > > > > > > 6389 /bin/cat.coreutils > > > > > > > 00016000-00017000 r--p 5000 fe:00 > > > > > > > 6389 /bin/cat.coreutils > > > > > > > 00017000-00018000 rw-p 6000 fe:00 > > > > > > > 6389 /bin/cat.coreutils > > > > > > > 00018000-00039000 rw-p 00:00 0 [heap] > > > > > > > 156000-16d000 r-xp fe:00 7193 /lib/ld- > > > > > > > 2.28.so > > > > > > > 16d000-16e000 r--p 00016000 fe:00 7193 /lib/ld- > > > > > > > 2.28.so > > > > > > > 16e000-16f000 rw-p 00017000 fe:00 7193 /lib/ld- > > > > > > > 2.28.so > > > > > > > 16f000-17 rw-p 00:00 0 > > > > > > > 17-172000 r-xp 00:00 0 [vdso] > > > > > > > 174000-176000 rw-p 00:00 0 > > > > > > > 176000-1555674000 r-xp 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-15556a rw-p 00:00 0 > > > > > > > 3fffb9-3fffbb1000 rw-p 00:00 0 [stack] > > > > > > > > > > > > > > After: > > > > > > > root@qemuriscv64:~# cat /proc/self/maps > > > > > > > 0001-00016000 r-xp fe:00 > > > > > > > 6389 /bin/cat.coreutils > > > > > > > 00016000-00017000 r--p 5000 fe:00 > > > > > > > 6389 /bin/cat.coreutils > > > > > > > 00017000-00018000 rw-p 6000 fe:00 > > > > > > > 6389 /bin/cat.coreutils > > > > > > > 2de81000-2dea2000 rw-p 00:00 0 [heap] > > > > > > > 3ff7eb6000-3ff7ed8000 rw-p 00:00 0 > > > > > > > 3ff7ed8000-3ff7fd6000 r-xp 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 00:00 0 > > > > > > > 3ff7fe4000-3ff7fe6000 r-xp 00:00 0 [vdso] > > > > > > > 3ff7fe6000-3ff7ffd000 r-xp 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-3ff800 rw-p 00:00 0 > > > > > > > 3fff888000-3fff8a9000 rw-p 00:00 0 [stack] > > > > > > > > > > > > > > Signed-off-by: Alexandre Ghiti > > > > > > > Acked-by: Paul Walmsley > > > > > > > Reviewed-by: Christoph Hellwig > > > > > > > Reviewed-by: Kees Cook > > > > > > > Reviewed-by: Luis Chamberlain > > > > > > > --- > > > > > > > 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 6legacy_va_layout4BIT > > > > > > > + 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. > > > > > > > > > > > >
Re: [PATCH v6 14/14] riscv: Make mmap allocation top-down by default
On 10/8/19 10:07 PM, Atish Patra wrote: On Tue, 2019-10-08 at 07:58 -0400, Alex Ghiti wrote: On 10/7/19 8:46 PM, Atish Patra wrote: On Mon, 2019-10-07 at 05:11 -0400, 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 0001-00016000 r-xp fe:00 6389 /bin/cat.coreutils 00016000-00017000 r--p 5000 fe:00 6389 /bin/cat.coreutils 00017000-00018000 rw-p 6000 fe:00 6389 /bin/cat.coreutils 00018000-00039000 rw-p 00:00 0 [heap] 156000-16d000 r-xp fe:00 7193 /lib/ld- 2.28.so 16d000-16e000 r--p 00016000 fe:00 7193 /lib/ld- 2.28.so 16e000-16f000 rw-p 00017000 fe:00 7193 /lib/ld- 2.28.so 16f000-17 rw-p 00:00 0 17-172000 r-xp 00:00 0 [vdso] 174000-176000 rw-p 00:00 0 176000-1555674000 r-xp 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-15556a rw-p 00:00 0 3fffb9-3fffbb1000 rw-p 00:00 0 [stack] After: root@qemuriscv64:~# cat /proc/self/maps 0001-00016000 r-xp fe:00 6389 /bin/cat.coreutils 00016000-00017000 r--p 5000 fe:00 6389 /bin/cat.coreutils 00017000-00018000 rw-p 6000 fe:00 6389 /bin/cat.coreutils 2de81000-2dea2000 rw-p 00:00 0 [heap] 3ff7eb6000-3ff7ed8000 rw-p 00:00 0 3ff7ed8000-3ff7fd6000 r-xp 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 00:00 0 3ff7fe4000-3ff7fe6000 r-xp 00:00 0 [vdso] 3ff7fe6000-3ff7ffd000 r-xp 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-3ff800 rw-p 00:00 0 3fff888000-3fff8a9000 rw-p 00:00 0 [stack] Signed-off-by: Alexandre Ghiti Acked-by: Paul Walmsley Reviewed-by: Christoph Hellwig Reviewed-by: Kees Cook Reviewed-by: Luis Chamberlain --- 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 6legacy_va_layout4BIT + 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. Randomization may not be the issue. I just removed ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT from the config and that seems to work. Here is the bottom-up layout with randomization on. Oups, sorry for my previous answer, I missed yours that landed in another folder. Removing ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT also removes randomization as this config selects ARCH_HAS_ELF_RANDOMIZE. You could remove ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT and selects by hand ARCH_HAS_ELF_RANDOMIZE but you would have to implement arch_mmap_rnd and arch_randomize_brk (elf-randomize.h). Ahh okay. The simplest would be to boot in legacy layout: I did not find a way to set this in kernel command line, but you can by modifying it directly in the code: https://elixir.bootlin.com/linux/v5.4-rc2/source/kernel/sysctl.c#L269 Setting this to 1 works. [root@fedora-riscv ~]# cat /proc/self/maps 156000-17 r-xp 103:01 280098
Re: [PATCH v6 14/14] riscv: Make mmap allocation top-down by default
On Tue, 2019-10-08 at 07:58 -0400, Alex Ghiti wrote: > On 10/7/19 8:46 PM, Atish Patra wrote: > > On Mon, 2019-10-07 at 05:11 -0400, 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 > > > > > 0001-00016000 r-xp fe:00 > > > > > 6389 /bin/cat.coreutils > > > > > 00016000-00017000 r--p 5000 fe:00 > > > > > 6389 /bin/cat.coreutils > > > > > 00017000-00018000 rw-p 6000 fe:00 > > > > > 6389 /bin/cat.coreutils > > > > > 00018000-00039000 rw-p 00:00 0 [heap] > > > > > 156000-16d000 r-xp fe:00 7193 /lib/ld- > > > > > 2.28.so > > > > > 16d000-16e000 r--p 00016000 fe:00 7193 /lib/ld- > > > > > 2.28.so > > > > > 16e000-16f000 rw-p 00017000 fe:00 7193 /lib/ld- > > > > > 2.28.so > > > > > 16f000-17 rw-p 00:00 0 > > > > > 17-172000 r-xp 00:00 0 [vdso] > > > > > 174000-176000 rw-p 00:00 0 > > > > > 176000-1555674000 r-xp 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-15556a rw-p 00:00 0 > > > > > 3fffb9-3fffbb1000 rw-p 00:00 0 [stack] > > > > > > > > > > After: > > > > > root@qemuriscv64:~# cat /proc/self/maps > > > > > 0001-00016000 r-xp fe:00 > > > > > 6389 /bin/cat.coreutils > > > > > 00016000-00017000 r--p 5000 fe:00 > > > > > 6389 /bin/cat.coreutils > > > > > 00017000-00018000 rw-p 6000 fe:00 > > > > > 6389 /bin/cat.coreutils > > > > > 2de81000-2dea2000 rw-p 00:00 0 [heap] > > > > > 3ff7eb6000-3ff7ed8000 rw-p 00:00 0 > > > > > 3ff7ed8000-3ff7fd6000 r-xp 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 00:00 0 > > > > > 3ff7fe4000-3ff7fe6000 r-xp 00:00 0 [vdso] > > > > > 3ff7fe6000-3ff7ffd000 r-xp 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-3ff800 rw-p 00:00 0 > > > > > 3fff888000-3fff8a9000 rw-p 00:00 0 [stack] > > > > > > > > > > Signed-off-by: Alexandre Ghiti > > > > > Acked-by: Paul Walmsley > > > > > Reviewed-by: Christoph Hellwig > > > > > Reviewed-by: Kees Cook > > > > > Reviewed-by: Luis Chamberlain > > > > > --- > > > > >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 6legacy_va_layout4BIT > > > > > + 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 >
Re: [PATCH v6 14/14] riscv: Make mmap allocation top-down by default
On 10/7/19 8:46 PM, Atish Patra wrote: On Mon, 2019-10-07 at 05:11 -0400, 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 0001-00016000 r-xp fe:00 6389 /bin/cat.coreutils 00016000-00017000 r--p 5000 fe:00 6389 /bin/cat.coreutils 00017000-00018000 rw-p 6000 fe:00 6389 /bin/cat.coreutils 00018000-00039000 rw-p 00:00 0 [heap] 156000-16d000 r-xp fe:00 7193 /lib/ld-2.28.so 16d000-16e000 r--p 00016000 fe:00 7193 /lib/ld-2.28.so 16e000-16f000 rw-p 00017000 fe:00 7193 /lib/ld-2.28.so 16f000-17 rw-p 00:00 0 17-172000 r-xp 00:00 0 [vdso] 174000-176000 rw-p 00:00 0 176000-1555674000 r-xp 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-15556a rw-p 00:00 0 3fffb9-3fffbb1000 rw-p 00:00 0 [stack] After: root@qemuriscv64:~# cat /proc/self/maps 0001-00016000 r-xp fe:00 6389 /bin/cat.coreutils 00016000-00017000 r--p 5000 fe:00 6389 /bin/cat.coreutils 00017000-00018000 rw-p 6000 fe:00 6389 /bin/cat.coreutils 2de81000-2dea2000 rw-p 00:00 0 [heap] 3ff7eb6000-3ff7ed8000 rw-p 00:00 0 3ff7ed8000-3ff7fd6000 r-xp 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 00:00 0 3ff7fe4000-3ff7fe6000 r-xp 00:00 0 [vdso] 3ff7fe6000-3ff7ffd000 r-xp 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-3ff800 rw-p 00:00 0 3fff888000-3fff8a9000 rw-p 00:00 0 [stack] Signed-off-by: Alexandre Ghiti Acked-by: Paul Walmsley Reviewed-by: Christoph Hellwig Reviewed-by: Kees Cook Reviewed-by: Luis Chamberlain --- 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 6legacy_va_layout4BIT + 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. Randomization may not be the issue. I just removed ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT from the config and that seems to work. Here is the bottom-up layout with randomization on. Oups, sorry for my previous answer, I missed yours that landed in another folder. Removing ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT also removes randomization as this config selects ARCH_HAS_ELF_RANDOMIZE. You could remove ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT and selects by hand ARCH_HAS_ELF_RANDOMIZE but you would have to implement arch_mmap_rnd and arch_randomize_brk (elf-randomize.h). The simplest would be to boot in legacy layout: I did not find a way to set this in kernel command line, but you can by modifying it directly in the code: https://elixir.bootlin.com/linux/v5.4-rc2/source/kernel/sysctl.c#L269 [root@fedora-riscv ~]# cat /proc/self/maps 156000-17 r-xp 103:01 280098/usr/lib64/ld-2.28.so 17-171000 r--p 00019000 103:01 280098/usr/lib64/ld-2.28.so
Re: [PATCH v6 14/14] riscv: Make mmap allocation top-down by default
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 0001-00016000 r-xp fe:00 6389 /bin/cat.coreutils 00016000-00017000 r--p 5000 fe:00 6389 /bin/cat.coreutils 00017000-00018000 rw-p 6000 fe:00 6389 /bin/cat.coreutils 00018000-00039000 rw-p 00:00 0 [heap] 156000-16d000 r-xp fe:00 7193 /lib/ld-2.28.so 16d000-16e000 r--p 00016000 fe:00 7193 /lib/ld-2.28.so 16e000-16f000 rw-p 00017000 fe:00 7193 /lib/ld-2.28.so 16f000-17 rw-p 00:00 0 17-172000 r-xp 00:00 0 [vdso] 174000-176000 rw-p 00:00 0 176000-1555674000 r-xp 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-15556a rw-p 00:00 0 3fffb9-3fffbb1000 rw-p 00:00 0 [stack] After: root@qemuriscv64:~# cat /proc/self/maps 0001-00016000 r-xp fe:00 6389 /bin/cat.coreutils 00016000-00017000 r--p 5000 fe:00 6389 /bin/cat.coreutils 00017000-00018000 rw-p 6000 fe:00 6389 /bin/cat.coreutils 2de81000-2dea2000 rw-p 00:00 0 [heap] 3ff7eb6000-3ff7ed8000 rw-p 00:00 0 3ff7ed8000-3ff7fd6000 r-xp 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 00:00 0 3ff7fe4000-3ff7fe6000 r-xp 00:00 0 [vdso] 3ff7fe6000-3ff7ffd000 r-xp 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-3ff800 rw-p 00:00 0 3fff888000-3fff8a9000 rw-p 00:00 0 [stack] Signed-off-by: Alexandre Ghiti Acked-by: Paul Walmsley Reviewed-by: Christoph Hellwig Reviewed-by: Kees Cook Reviewed-by: Luis Chamberlain --- 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
Re: [PATCH v6 14/14] riscv: Make mmap allocation top-down by default
On Mon, 2019-10-07 at 05:11 -0400, 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 > > > 0001-00016000 r-xp fe:00 > > > 6389 /bin/cat.coreutils > > > 00016000-00017000 r--p 5000 fe:00 > > > 6389 /bin/cat.coreutils > > > 00017000-00018000 rw-p 6000 fe:00 > > > 6389 /bin/cat.coreutils > > > 00018000-00039000 rw-p 00:00 0 [heap] > > > 156000-16d000 r-xp fe:00 7193 /lib/ld-2.28.so > > > 16d000-16e000 r--p 00016000 fe:00 7193 /lib/ld-2.28.so > > > 16e000-16f000 rw-p 00017000 fe:00 7193 /lib/ld-2.28.so > > > 16f000-17 rw-p 00:00 0 > > > 17-172000 r-xp 00:00 0 [vdso] > > > 174000-176000 rw-p 00:00 0 > > > 176000-1555674000 r-xp 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-15556a rw-p 00:00 0 > > > 3fffb9-3fffbb1000 rw-p 00:00 0 [stack] > > > > > > After: > > > root@qemuriscv64:~# cat /proc/self/maps > > > 0001-00016000 r-xp fe:00 > > > 6389 /bin/cat.coreutils > > > 00016000-00017000 r--p 5000 fe:00 > > > 6389 /bin/cat.coreutils > > > 00017000-00018000 rw-p 6000 fe:00 > > > 6389 /bin/cat.coreutils > > > 2de81000-2dea2000 rw-p 00:00 0 [heap] > > > 3ff7eb6000-3ff7ed8000 rw-p 00:00 0 > > > 3ff7ed8000-3ff7fd6000 r-xp 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 00:00 0 > > > 3ff7fe4000-3ff7fe6000 r-xp 00:00 0 [vdso] > > > 3ff7fe6000-3ff7ffd000 r-xp 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-3ff800 rw-p 00:00 0 > > > 3fff888000-3fff8a9000 rw-p 00:00 0 [stack] > > > > > > Signed-off-by: Alexandre Ghiti > > > Acked-by: Paul Walmsley > > > Reviewed-by: Christoph Hellwig > > > Reviewed-by: Kees Cook > > > Reviewed-by: Luis Chamberlain > > > --- > > > 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 6legacy_va_layout4BIT > > > + 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. Randomization may not be the issue. I just removed ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT from the config and that seems to work. Here is the bottom-up layout with randomization on. [root@fedora-riscv ~]# cat /proc/self/maps 156000-17 r-xp 103:01 280098/usr/lib64/ld-2.28.so 17-171000 r--p 00019000 103:01 280098/usr/lib64/ld-2.28.so 171000-172000 rw-p 0001a000 103:01 280098/usr/lib64/ld-2.28.so 172000-173000 rw-p
Re: [PATCH v6 14/14] riscv: Make mmap allocation top-down by default
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 0001-00016000 r-xp fe:00 6389 /bin/cat.coreutils 00016000-00017000 r--p 5000 fe:00 6389 /bin/cat.coreutils 00017000-00018000 rw-p 6000 fe:00 6389 /bin/cat.coreutils 00018000-00039000 rw-p 00:00 0 [heap] 156000-16d000 r-xp fe:00 7193 /lib/ld-2.28.so 16d000-16e000 r--p 00016000 fe:00 7193 /lib/ld-2.28.so 16e000-16f000 rw-p 00017000 fe:00 7193 /lib/ld-2.28.so 16f000-17 rw-p 00:00 0 17-172000 r-xp 00:00 0 [vdso] 174000-176000 rw-p 00:00 0 176000-1555674000 r-xp 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-15556a rw-p 00:00 0 3fffb9-3fffbb1000 rw-p 00:00 0 [stack] After: root@qemuriscv64:~# cat /proc/self/maps 0001-00016000 r-xp fe:00 6389 /bin/cat.coreutils 00016000-00017000 r--p 5000 fe:00 6389 /bin/cat.coreutils 00017000-00018000 rw-p 6000 fe:00 6389 /bin/cat.coreutils 2de81000-2dea2000 rw-p 00:00 0 [heap] 3ff7eb6000-3ff7ed8000 rw-p 00:00 0 3ff7ed8000-3ff7fd6000 r-xp 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 00:00 0 3ff7fe4000-3ff7fe6000 r-xp 00:00 0 [vdso] 3ff7fe6000-3ff7ffd000 r-xp 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-3ff800 rw-p 00:00 0 3fff888000-3fff8a9000 rw-p 00:00 0 [stack] Signed-off-by: Alexandre Ghiti Acked-by: Paul Walmsley Reviewed-by: Christoph Hellwig Reviewed-by: Kees Cook Reviewed-by: Luis Chamberlain --- 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
Re: [PATCH v6 14/14] riscv: Make mmap allocation top-down by default
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 > 0001-00016000 r-xp fe:00 6389 /bin/cat.coreutils > 00016000-00017000 r--p 5000 fe:00 6389 /bin/cat.coreutils > 00017000-00018000 rw-p 6000 fe:00 6389 /bin/cat.coreutils > 00018000-00039000 rw-p 00:00 0 [heap] > 156000-16d000 r-xp fe:00 7193 /lib/ld-2.28.so > 16d000-16e000 r--p 00016000 fe:00 7193 /lib/ld-2.28.so > 16e000-16f000 rw-p 00017000 fe:00 7193 /lib/ld-2.28.so > 16f000-17 rw-p 00:00 0 > 17-172000 r-xp 00:00 0 [vdso] > 174000-176000 rw-p 00:00 0 > 176000-1555674000 r-xp 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-15556a rw-p 00:00 0 > 3fffb9-3fffbb1000 rw-p 00:00 0 [stack] > > After: > root@qemuriscv64:~# cat /proc/self/maps > 0001-00016000 r-xp fe:00 6389 /bin/cat.coreutils > 00016000-00017000 r--p 5000 fe:00 6389 /bin/cat.coreutils > 00017000-00018000 rw-p 6000 fe:00 6389 /bin/cat.coreutils > 2de81000-2dea2000 rw-p 00:00 0 [heap] > 3ff7eb6000-3ff7ed8000 rw-p 00:00 0 > 3ff7ed8000-3ff7fd6000 r-xp 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 00:00 0 > 3ff7fe4000-3ff7fe6000 r-xp 00:00 0 [vdso] > 3ff7fe6000-3ff7ffd000 r-xp 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-3ff800 rw-p 00:00 0 > 3fff888000-3fff8a9000 rw-p 00:00 0 [stack] > > Signed-off-by: Alexandre Ghiti > Acked-by: Paul Walmsley > Reviewed-by: Christoph Hellwig > Reviewed-by: Kees Cook > Reviewed-by: Luis Chamberlain > --- > 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. -- Regards, Atish
[PATCH v6 14/14] riscv: Make mmap allocation top-down by default
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 0001-00016000 r-xp fe:00 6389 /bin/cat.coreutils 00016000-00017000 r--p 5000 fe:00 6389 /bin/cat.coreutils 00017000-00018000 rw-p 6000 fe:00 6389 /bin/cat.coreutils 00018000-00039000 rw-p 00:00 0 [heap] 156000-16d000 r-xp fe:00 7193 /lib/ld-2.28.so 16d000-16e000 r--p 00016000 fe:00 7193 /lib/ld-2.28.so 16e000-16f000 rw-p 00017000 fe:00 7193 /lib/ld-2.28.so 16f000-17 rw-p 00:00 0 17-172000 r-xp 00:00 0 [vdso] 174000-176000 rw-p 00:00 0 176000-1555674000 r-xp 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-15556a rw-p 00:00 0 3fffb9-3fffbb1000 rw-p 00:00 0 [stack] After: root@qemuriscv64:~# cat /proc/self/maps 0001-00016000 r-xp fe:00 6389 /bin/cat.coreutils 00016000-00017000 r--p 5000 fe:00 6389 /bin/cat.coreutils 00017000-00018000 rw-p 6000 fe:00 6389 /bin/cat.coreutils 2de81000-2dea2000 rw-p 00:00 0 [heap] 3ff7eb6000-3ff7ed8000 rw-p 00:00 0 3ff7ed8000-3ff7fd6000 r-xp 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 00:00 0 3ff7fe4000-3ff7fe6000 r-xp 00:00 0 [vdso] 3ff7fe6000-3ff7ffd000 r-xp 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-3ff800 rw-p 00:00 0 3fff888000-3fff8a9000 rw-p 00:00 0 [stack] Signed-off-by: Alexandre Ghiti Acked-by: Paul Walmsley Reviewed-by: Christoph Hellwig Reviewed-by: Kees Cook Reviewed-by: Luis Chamberlain --- 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 -- 2.20.1
