From: Atish Patra <Atish.Patra@wdc.com>
To: "alex@ghiti.fr" <alex@ghiti.fr>
Cc: "ralf@linux-mips.org" <ralf@linux-mips.org>,
"keescook@chromium.org" <keescook@chromium.org>,
"palmer@sifive.com" <palmer@sifive.com>,
"aou@eecs.berkeley.edu" <aou@eecs.berkeley.edu>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"will.deacon@arm.com" <will.deacon@arm.com>,
"paul.walmsley@sifive.com" <paul.walmsley@sifive.com>,
"paul.burton@mips.com" <paul.burton@mips.com>,
"linux@armlinux.org.uk" <linux@armlinux.org.uk>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"hch@lst.de" <hch@lst.de>,
"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
"viro@zeniv.linux.org.uk" <viro@zeniv.linux.org.uk>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
"jhogan@kernel.org" <jhogan@kernel.org>,
"mcgrof@kernel.org" <mcgrof@kernel.org>,
"linux-riscv@lists.infradead.org"
<linux-riscv@lists.infradead.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v6 14/14] riscv: Make mmap allocation top-down by default
Date: Tue, 8 Oct 2019 00:46:05 +0000 [thread overview]
Message-ID: <daeb33415751ef16a717f6ff6a29486110c503d7.camel@wdc.com> (raw)
In-Reply-To: <60b52f20-a2c7-dee9-7cf3-a727f07400b9@ghiti.fr>
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
> > > 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@ghiti.fr>
> > > Acked-by: Paul Walmsley <paul.walmsley@sifive.com>
> > > Reviewed-by: Christoph Hellwig <hch@lst.de>
> > > Reviewed-by: Kees Cook <keescook@chromium.org>
> > > Reviewed-by: Luis Chamberlain <mcgrof@kernel.org>
> > > ---
> > > 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
1555556000-1555570000 r-xp 00000000 103:01
280098 /usr/lib64/ld-2.28.so
1555570000-1555571000 r--p 00019000 103:01
280098 /usr/lib64/ld-2.28.so
1555571000-1555572000 rw-p 0001a000 103:01
280098 /usr/lib64/ld-2.28.so
1555572000-1555573000 rw-p 00000000 00:00 0
1555573000-1555575000 r-xp 00000000 00:00
0 [vdso]
1555575000-1555576000 r--p 00000000 103:01
50936 /usr/lib/locale/en_US.utf8/LC_IDENTIFICAT
ION
1555576000-155557d000 r--s 00000000 103:01
280826 /usr/lib64/gconv/gconv-modules.cache
155557d000-155557e000 r--p 00000000 103:01
50937 /usr/lib/locale/en_US.utf8/LC_MEASUREMENT
155557e000-155557f000 r--p 00000000 103:01
50939 /usr/lib/locale/en_US.utf8/LC_TELEPHONE
155557f000-1555580000 r--p 00000000 103:01
3706 /usr/lib/locale/en_US.utf8/LC_ADDRESS
1555580000-1555581000 r--p 00000000 103:01
50944 /usr/lib/locale/en_US.utf8/LC_NAME
1555581000-1555582000 r--p 00000000 103:01
3775 /usr/lib/locale/en_US.utf8/LC_PAPER
1555582000-1555583000 r--p 00000000 103:01
3758 /usr/lib/locale/en_US.utf8/LC_MESSAGES/SY
S_LC_MESSAGES
1555583000-1555584000 r--p 00000000 103:01
50938 /usr/lib/locale/en_US.utf8/LC_MONETARY
1555584000-1555585000 r--p 00000000 103:01
50940 /usr/lib/locale/en_US.utf8/LC_TIME
1555585000-1555586000 r--p 00000000 103:01
50945 /usr/lib/locale/en_US.utf8/LC_NUMERIC
1555590000-1555592000 rw-p 00000000 00:00 0
1555592000-15556b1000 r-xp 00000000 103:01
280105 /usr/lib64/libc-2.28.so
15556b1000-15556b5000 r--p 0011e000 103:01
280105 /usr/lib64/libc-2.28.so
15556b5000-15556b7000 rw-p 00122000 103:01
280105 /usr/lib64/libc-2.28.so
15556b7000-15556bb000 rw-p 00000000 00:00 0
15556bb000-1555933000 r--p 00000000 103:01
3755 /usr/lib/locale/en_US.utf8/LC_COLLATE
1555933000-1555986000 r--p 00000000 103:01
50942 /usr/lib/locale/en_US.utf8/LC_CTYPE
1555986000-15559a8000 rw-p 00000000 00:00 0
2aaaaaa000-2aaaab1000 r-xp 00000000 103:01
283975 /usr/bin/cat
2aaaab1000-2aaaab2000 r--p 00006000 103:01
283975 /usr/bin/cat
2aaaab2000-2aaaab3000 rw-p 00007000 103:01
283975 /usr/bin/cat
2aaaab3000-2aaaad4000 rw-p 00000000 00:00
0 [heap]
3fffc97000-3fffcb8000 rw-p 00000000 00:00
0 [stack]
> 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
> :)
>
It stucks while booting. So I am not sure how to figure out which
program stalls. It is difficult to figure out from boot log as it
stucks at different places but soon after systemd starts.
> 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
--
Regards,
Atish
WARNING: multiple messages have this Message-ID (diff)
From: Atish Patra <Atish.Patra@wdc.com>
To: "alex@ghiti.fr" <alex@ghiti.fr>
Cc: "aou@eecs.berkeley.edu" <aou@eecs.berkeley.edu>,
"keescook@chromium.org" <keescook@chromium.org>,
"jhogan@kernel.org" <jhogan@kernel.org>,
"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
"palmer@sifive.com" <palmer@sifive.com>,
"will.deacon@arm.com" <will.deacon@arm.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"ralf@linux-mips.org" <ralf@linux-mips.org>,
"linux@armlinux.org.uk" <linux@armlinux.org.uk>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"paul.burton@mips.com" <paul.burton@mips.com>,
"linux-riscv@lists.infradead.org"
<linux-riscv@lists.infradead.org>,
"viro@zeniv.linux.org.uk" <viro@zeniv.linux.org.uk>,
"paul.walmsley@sifive.com" <paul.walmsley@sifive.com>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"hch@lst.de" <hch@lst.de>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"mcgrof@kernel.org" <mcgrof@kernel.org>
Subject: Re: [PATCH v6 14/14] riscv: Make mmap allocation top-down by default
Date: Tue, 8 Oct 2019 00:46:05 +0000 [thread overview]
Message-ID: <daeb33415751ef16a717f6ff6a29486110c503d7.camel@wdc.com> (raw)
In-Reply-To: <60b52f20-a2c7-dee9-7cf3-a727f07400b9@ghiti.fr>
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
> > > 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@ghiti.fr>
> > > Acked-by: Paul Walmsley <paul.walmsley@sifive.com>
> > > Reviewed-by: Christoph Hellwig <hch@lst.de>
> > > Reviewed-by: Kees Cook <keescook@chromium.org>
> > > Reviewed-by: Luis Chamberlain <mcgrof@kernel.org>
> > > ---
> > > 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
1555556000-1555570000 r-xp 00000000 103:01
280098 /usr/lib64/ld-2.28.so
1555570000-1555571000 r--p 00019000 103:01
280098 /usr/lib64/ld-2.28.so
1555571000-1555572000 rw-p 0001a000 103:01
280098 /usr/lib64/ld-2.28.so
1555572000-1555573000 rw-p 00000000 00:00 0
1555573000-1555575000 r-xp 00000000 00:00
0 [vdso]
1555575000-1555576000 r--p 00000000 103:01
50936 /usr/lib/locale/en_US.utf8/LC_IDENTIFICAT
ION
1555576000-155557d000 r--s 00000000 103:01
280826 /usr/lib64/gconv/gconv-modules.cache
155557d000-155557e000 r--p 00000000 103:01
50937 /usr/lib/locale/en_US.utf8/LC_MEASUREMENT
155557e000-155557f000 r--p 00000000 103:01
50939 /usr/lib/locale/en_US.utf8/LC_TELEPHONE
155557f000-1555580000 r--p 00000000 103:01
3706 /usr/lib/locale/en_US.utf8/LC_ADDRESS
1555580000-1555581000 r--p 00000000 103:01
50944 /usr/lib/locale/en_US.utf8/LC_NAME
1555581000-1555582000 r--p 00000000 103:01
3775 /usr/lib/locale/en_US.utf8/LC_PAPER
1555582000-1555583000 r--p 00000000 103:01
3758 /usr/lib/locale/en_US.utf8/LC_MESSAGES/SY
S_LC_MESSAGES
1555583000-1555584000 r--p 00000000 103:01
50938 /usr/lib/locale/en_US.utf8/LC_MONETARY
1555584000-1555585000 r--p 00000000 103:01
50940 /usr/lib/locale/en_US.utf8/LC_TIME
1555585000-1555586000 r--p 00000000 103:01
50945 /usr/lib/locale/en_US.utf8/LC_NUMERIC
1555590000-1555592000 rw-p 00000000 00:00 0
1555592000-15556b1000 r-xp 00000000 103:01
280105 /usr/lib64/libc-2.28.so
15556b1000-15556b5000 r--p 0011e000 103:01
280105 /usr/lib64/libc-2.28.so
15556b5000-15556b7000 rw-p 00122000 103:01
280105 /usr/lib64/libc-2.28.so
15556b7000-15556bb000 rw-p 00000000 00:00 0
15556bb000-1555933000 r--p 00000000 103:01
3755 /usr/lib/locale/en_US.utf8/LC_COLLATE
1555933000-1555986000 r--p 00000000 103:01
50942 /usr/lib/locale/en_US.utf8/LC_CTYPE
1555986000-15559a8000 rw-p 00000000 00:00 0
2aaaaaa000-2aaaab1000 r-xp 00000000 103:01
283975 /usr/bin/cat
2aaaab1000-2aaaab2000 r--p 00006000 103:01
283975 /usr/bin/cat
2aaaab2000-2aaaab3000 rw-p 00007000 103:01
283975 /usr/bin/cat
2aaaab3000-2aaaad4000 rw-p 00000000 00:00
0 [heap]
3fffc97000-3fffcb8000 rw-p 00000000 00:00
0 [stack]
> 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
> :)
>
It stucks while booting. So I am not sure how to figure out which
program stalls. It is difficult to figure out from boot log as it
stucks at different places but soon after systemd starts.
> 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
--
Regards,
Atish
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
WARNING: multiple messages have this Message-ID (diff)
From: Atish Patra <Atish.Patra@wdc.com>
To: "alex@ghiti.fr" <alex@ghiti.fr>
Cc: "aou@eecs.berkeley.edu" <aou@eecs.berkeley.edu>,
"keescook@chromium.org" <keescook@chromium.org>,
"jhogan@kernel.org" <jhogan@kernel.org>,
"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
"palmer@sifive.com" <palmer@sifive.com>,
"will.deacon@arm.com" <will.deacon@arm.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"ralf@linux-mips.org" <ralf@linux-mips.org>,
"linux@armlinux.org.uk" <linux@armlinux.org.uk>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"paul.burton@mips.com" <paul.burton@mips.com>,
"linux-riscv@lists.infradead.org"
<linux-riscv@lists.infradead.org>,
"viro@zeniv.linux.org.uk" <viro@zeniv.linux.org.uk>,
"paul.walmsley@sifive.com" <paul.walmsley@sifive.com>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"hch@lst.de" <hch@lst.de>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"mcgrof@kernel.org" <mcgrof@kernel.org>
Subject: Re: [PATCH v6 14/14] riscv: Make mmap allocation top-down by default
Date: Tue, 8 Oct 2019 00:46:05 +0000 [thread overview]
Message-ID: <daeb33415751ef16a717f6ff6a29486110c503d7.camel@wdc.com> (raw)
In-Reply-To: <60b52f20-a2c7-dee9-7cf3-a727f07400b9@ghiti.fr>
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
> > > 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@ghiti.fr>
> > > Acked-by: Paul Walmsley <paul.walmsley@sifive.com>
> > > Reviewed-by: Christoph Hellwig <hch@lst.de>
> > > Reviewed-by: Kees Cook <keescook@chromium.org>
> > > Reviewed-by: Luis Chamberlain <mcgrof@kernel.org>
> > > ---
> > > 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
1555556000-1555570000 r-xp 00000000 103:01
280098 /usr/lib64/ld-2.28.so
1555570000-1555571000 r--p 00019000 103:01
280098 /usr/lib64/ld-2.28.so
1555571000-1555572000 rw-p 0001a000 103:01
280098 /usr/lib64/ld-2.28.so
1555572000-1555573000 rw-p 00000000 00:00 0
1555573000-1555575000 r-xp 00000000 00:00
0 [vdso]
1555575000-1555576000 r--p 00000000 103:01
50936 /usr/lib/locale/en_US.utf8/LC_IDENTIFICAT
ION
1555576000-155557d000 r--s 00000000 103:01
280826 /usr/lib64/gconv/gconv-modules.cache
155557d000-155557e000 r--p 00000000 103:01
50937 /usr/lib/locale/en_US.utf8/LC_MEASUREMENT
155557e000-155557f000 r--p 00000000 103:01
50939 /usr/lib/locale/en_US.utf8/LC_TELEPHONE
155557f000-1555580000 r--p 00000000 103:01
3706 /usr/lib/locale/en_US.utf8/LC_ADDRESS
1555580000-1555581000 r--p 00000000 103:01
50944 /usr/lib/locale/en_US.utf8/LC_NAME
1555581000-1555582000 r--p 00000000 103:01
3775 /usr/lib/locale/en_US.utf8/LC_PAPER
1555582000-1555583000 r--p 00000000 103:01
3758 /usr/lib/locale/en_US.utf8/LC_MESSAGES/SY
S_LC_MESSAGES
1555583000-1555584000 r--p 00000000 103:01
50938 /usr/lib/locale/en_US.utf8/LC_MONETARY
1555584000-1555585000 r--p 00000000 103:01
50940 /usr/lib/locale/en_US.utf8/LC_TIME
1555585000-1555586000 r--p 00000000 103:01
50945 /usr/lib/locale/en_US.utf8/LC_NUMERIC
1555590000-1555592000 rw-p 00000000 00:00 0
1555592000-15556b1000 r-xp 00000000 103:01
280105 /usr/lib64/libc-2.28.so
15556b1000-15556b5000 r--p 0011e000 103:01
280105 /usr/lib64/libc-2.28.so
15556b5000-15556b7000 rw-p 00122000 103:01
280105 /usr/lib64/libc-2.28.so
15556b7000-15556bb000 rw-p 00000000 00:00 0
15556bb000-1555933000 r--p 00000000 103:01
3755 /usr/lib/locale/en_US.utf8/LC_COLLATE
1555933000-1555986000 r--p 00000000 103:01
50942 /usr/lib/locale/en_US.utf8/LC_CTYPE
1555986000-15559a8000 rw-p 00000000 00:00 0
2aaaaaa000-2aaaab1000 r-xp 00000000 103:01
283975 /usr/bin/cat
2aaaab1000-2aaaab2000 r--p 00006000 103:01
283975 /usr/bin/cat
2aaaab2000-2aaaab3000 rw-p 00007000 103:01
283975 /usr/bin/cat
2aaaab3000-2aaaad4000 rw-p 00000000 00:00
0 [heap]
3fffc97000-3fffcb8000 rw-p 00000000 00:00
0 [stack]
> 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
> :)
>
It stucks while booting. So I am not sure how to figure out which
program stalls. It is difficult to figure out from boot log as it
stucks at different places but soon after systemd starts.
> 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
--
Regards,
Atish
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-10-08 0:46 UTC|newest]
Thread overview: 92+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-08 6:17 [PATCH v6 00/14] Provide generic top-down mmap layout functions Alexandre Ghiti
2019-08-08 6:17 ` Alexandre Ghiti
2019-08-08 6:17 ` Alexandre Ghiti
2019-08-08 6:17 ` [PATCH v6 01/14] mm, fs: Move randomize_stack_top from fs to mm Alexandre Ghiti
2019-08-08 6:17 ` Alexandre Ghiti
2019-08-08 6:17 ` Alexandre Ghiti
2019-08-08 6:17 ` [PATCH v6 02/14] arm64: Make use of is_compat_task instead of hardcoding this test Alexandre Ghiti
2019-08-08 6:17 ` Alexandre Ghiti
2019-08-08 6:17 ` Alexandre Ghiti
2019-08-08 6:17 ` [PATCH v6 03/14] arm64: Consider stack randomization for mmap base only when necessary Alexandre Ghiti
2019-08-08 6:17 ` Alexandre Ghiti
2019-08-08 6:17 ` Alexandre Ghiti
2019-08-08 6:17 ` [PATCH v6 04/14] arm64, mm: Move generic mmap layout functions to mm Alexandre Ghiti
2019-08-08 6:17 ` Alexandre Ghiti
2019-08-08 6:17 ` Alexandre Ghiti
2019-08-08 6:17 ` [PATCH v6 05/14] arm64, mm: Make randomization selected by generic topdown mmap layout Alexandre Ghiti
2019-08-08 6:17 ` Alexandre Ghiti
2019-08-08 6:17 ` Alexandre Ghiti
2019-08-08 6:17 ` [PATCH v6 06/14] arm: Properly account for stack randomization and stack guard gap Alexandre Ghiti
2019-08-08 6:17 ` Alexandre Ghiti
2019-08-08 6:17 ` Alexandre Ghiti
2019-08-08 6:17 ` [PATCH v6 07/14] arm: Use STACK_TOP when computing mmap base address Alexandre Ghiti
2019-08-08 6:17 ` Alexandre Ghiti
2019-08-08 6:17 ` Alexandre Ghiti
2019-08-08 6:17 ` [PATCH v6 08/14] arm: Use generic mmap top-down layout and brk randomization Alexandre Ghiti
2019-08-08 6:17 ` Alexandre Ghiti
2019-08-08 6:17 ` Alexandre Ghiti
2019-08-08 6:17 ` [PATCH v6 09/14] mips: Properly account for stack randomization and stack guard gap Alexandre Ghiti
2019-08-08 6:17 ` Alexandre Ghiti
2019-08-08 6:17 ` Alexandre Ghiti
2019-08-08 9:16 ` Sergei Shtylyov
2019-08-08 9:16 ` Sergei Shtylyov
2019-08-08 9:16 ` Sergei Shtylyov
2019-08-09 9:44 ` Alexandre Ghiti
2019-08-09 9:44 ` Alexandre Ghiti
2019-08-09 9:44 ` Alexandre Ghiti
2019-08-08 6:17 ` [PATCH v6 10/14] mips: Use STACK_TOP when computing mmap base address Alexandre Ghiti
2019-08-08 6:17 ` Alexandre Ghiti
2019-08-08 6:17 ` Alexandre Ghiti
2019-08-08 6:17 ` [PATCH v6 11/14] mips: Adjust brk randomization offset to fit generic version Alexandre Ghiti
2019-08-08 6:17 ` Alexandre Ghiti
2019-08-08 6:17 ` Alexandre Ghiti
2019-08-08 9:19 ` Sergei Shtylyov
2019-08-08 9:19 ` Sergei Shtylyov
2019-08-08 9:19 ` Sergei Shtylyov
2019-08-09 9:45 ` Alexandre Ghiti
2019-08-09 9:45 ` Alexandre Ghiti
2019-08-09 9:45 ` Alexandre Ghiti
2019-08-08 6:17 ` [PATCH v6 12/14] mips: Replace arch specific way to determine 32bit task with " Alexandre Ghiti
2019-08-08 6:17 ` Alexandre Ghiti
2019-08-08 6:17 ` Alexandre Ghiti
2019-08-08 6:17 ` [PATCH v6 13/14] mips: Use generic mmap top-down layout and brk randomization Alexandre Ghiti
2019-08-08 6:17 ` Alexandre Ghiti
2019-08-08 6:17 ` Alexandre Ghiti
2019-08-08 6:17 ` [PATCH v6 14/14] riscv: Make mmap allocation top-down by default Alexandre Ghiti
2019-08-08 6:17 ` Alexandre Ghiti
2019-08-08 6:17 ` Alexandre Ghiti
2019-10-05 2:12 ` Atish Patra
2019-10-05 2:12 ` Atish Patra
2019-10-05 2:12 ` Atish Patra
2019-10-05 2:12 ` Atish Patra
2019-10-07 9:11 ` Alex Ghiti
2019-10-07 9:11 ` Alex Ghiti
2019-10-07 9:11 ` Alex Ghiti
2019-10-07 9:11 ` Alex Ghiti
2019-10-08 0:46 ` Atish Patra [this message]
2019-10-08 0:46 ` Atish Patra
2019-10-08 0:46 ` Atish Patra
2019-10-08 0:46 ` Atish Patra
2019-10-08 11:58 ` Alex Ghiti
2019-10-08 11:58 ` Alex Ghiti
2019-10-08 11:58 ` Alex Ghiti
2019-10-08 11:58 ` Alex Ghiti
2019-10-09 2:07 ` Atish Patra
2019-10-09 2:07 ` Atish Patra
2019-10-09 2:07 ` Atish Patra
2019-10-09 2:07 ` Atish Patra
2019-10-09 18:39 ` Alex Ghiti
2019-10-09 18:39 ` Alex Ghiti
2019-10-09 18:39 ` Alex Ghiti
2019-10-09 18:39 ` Alex Ghiti
2019-10-15 0:31 ` Atish Patra
2019-10-15 0:31 ` Atish Patra
2019-10-15 0:31 ` Atish Patra
2019-10-15 0:31 ` Atish Patra
2019-10-15 7:48 ` Andreas Schwab
2019-10-15 7:48 ` Andreas Schwab
2019-10-15 7:48 ` Andreas Schwab
2019-10-08 9:19 ` Alex Ghiti
2019-10-08 9:19 ` Alex Ghiti
2019-10-08 9:19 ` Alex Ghiti
2019-10-08 9:19 ` Alex Ghiti
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=daeb33415751ef16a717f6ff6a29486110c503d7.camel@wdc.com \
--to=atish.patra@wdc.com \
--cc=akpm@linux-foundation.org \
--cc=alex@ghiti.fr \
--cc=aou@eecs.berkeley.edu \
--cc=catalin.marinas@arm.com \
--cc=hch@lst.de \
--cc=jhogan@kernel.org \
--cc=keescook@chromium.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux@armlinux.org.uk \
--cc=mcgrof@kernel.org \
--cc=palmer@sifive.com \
--cc=paul.burton@mips.com \
--cc=paul.walmsley@sifive.com \
--cc=ralf@linux-mips.org \
--cc=viro@zeniv.linux.org.uk \
--cc=will.deacon@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.