[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <8130e50c-01e2-45c3-a516-45f5499311f2@app.fastmail.com>
Date: Wed, 11 Sep 2024 07:25:08 +0000
From: "Arnd Bergmann" <arnd@...db.de>
To: "Charlie Jenkins" <charlie@...osinc.com>,
"Liam R. Howlett" <Liam.Howlett@...cle.com>,
"Catalin Marinas" <catalin.marinas@....com>, guoren <guoren@...nel.org>,
"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>,
"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>,
"Vlastimil Babka" <vbabka@...e.cz>,
"Lorenzo Stoakes" <lorenzo.stoakes@...cle.com>, shuah <shuah@...nel.org>,
"Christoph Hellwig" <hch@...radead.org>,
"Michal Hocko" <mhocko@...e.com>,
"Kirill A. Shutemov" <kirill@...temov.name>,
"Chris Torek" <chris.torek@...il.com>,
Linux-Arch <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" <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, linux-abi-devel@...ts.sourceforge.net
Subject: Re: [PATCH RFC v3 1/2] mm: Add personality flag to limit address to 47 bits
On Wed, Sep 11, 2024, at 00:45, Charlie Jenkins wrote:
> On Tue, Sep 10, 2024 at 03:08:14PM -0400, Liam R. Howlett wrote:
>
> I responded to Arnd in the other thread, but I am still not convinced
> that the solution that x86 and arm64 have selected is the best solution.
> The solution of defaulting to 47 bits does allow applications the
> ability to get addresses that are below 47 bits. However, due to
> differences across architectures it doesn't seem possible to have all
> architectures default to the same value. Additionally, this flag will be
> able to help users avoid potential bugs where a hint address is passed
> that causes upper bits of a VA to be used.
>
> The other issue I have with this is that if there is not a hint address
> specified to be greater than 47 bits on x86, then mmap() may return an
> address that is greater than 47-bits. The documentation in
> Documentation/arch/x86/x86_64/5level-paging.rst says:
>
> "If hint address set above 47-bit, but MAP_FIXED is not specified, we try
> to look for unmapped area by specified address. If it's already
> occupied, we look for unmapped area in *full* address space, rather than
> from 47-bit window."
This is also in the commit message of b569bab78d8d ("x86/mm: Prepare
to expose larger address space to userspace"), which introduced it.
However, I don't actually see the fallback to the full address space,
instead the actual behavior seems to be the same as arm64.
Am I missing something in the x86 implementation, or do we just
need to update the documentation?
Arnd
Powered by blists - more mailing lists