Message-Id: <89d21669-8daa-4225-b6d2-33d439ebd746@app.fastmail.com>
Date: Tue, 10 Sep 2024 09:13:33 +0000
From: "Arnd Bergmann" <arnd@...db.de>
To: "Charlie Jenkins" <charlie@...osinc.com>,
 "Lorenzo Stoakes" <lorenzo.stoakes@...cle.com>
Cc: "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>, guoren <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 <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 Mon, Sep 9, 2024, at 23:22, Charlie Jenkins wrote:
> On Fri, Sep 06, 2024 at 10:52:34AM +0100, Lorenzo Stoakes wrote:
>> On Fri, Sep 06, 2024 at 09:14:08AM GMT, Arnd Bergmann wrote:
>> The intent is to optionally be able to run a process that keeps higher bits
>> free for tagging and to be sure no memory mapping in the process will
>> clobber these (correct me if I'm wrong Charlie! :)
>> 
>> So you really wouldn't want this if you are using tagged pointers, you'd
>> want to be sure literally nothing touches the higher bits.

My understanding was that the purpose of the existing design
is to allow applications to ask for a high address without having
to resort to the complexity of MAP_FIXED.

In particular, I'm sure there is precedent for applications that
want both tagged pointers (for most mappings) and untagged pointers
(for large mappings). With a per-mm_struct or per-task_struct
setting you can't do that.

> Various architectures handle the hint address differently, but it
> appears that the only case across any architecture where an address
> above 47 bits will be returned is if the application had a hint address
> with a value greater than 47 bits and was using the MAP_FIXED flag.
> MAP_FIXED bypasses all other checks so I was assuming that it would be
> logical for MAP_FIXED to bypass this as well. If MAP_FIXED is not set,
> then the intent is for no hint address to cause a value greater than 47
> bits to be returned.

I don't think the MAP_FIXED case is that interesting here because
it has to work in both fixed and non-fixed mappings.

>> This would be more consistent vs. other arches.
>
> Yes riscv is an outlier here. The reason I am pushing for something like
> a flag to restrict the address space rather than setting it to be the
> default is it seems like if applications are relying on upper bits to be
> free, then they should be explicitly asking the kernel to keep them free
> rather than assuming them to be free.

Let's see what the other architectures do and then come up with
a way that fixes the pointer tagging case first on those that are
broken. We can see if there needs to be an extra flag after that.
Here is what I found:

- x86_64 uses DEFAULT_MAP_WINDOW of BIT(47), uses a 57 bit
  address space when an addr hint is passed.
- arm64 uses DEFAULT_MAP_WINDOW of BIT(47) or BIT(48), returns
  higher 52-bit addresses when either a hint is passed or
  CONFIG_EXPERT and CONFIG_ARM64_FORCE_52BIT is set (this
  is a debugging option)
- ppc64 uses a DEFAULT_MAP_WINDOW of BIT(47) or BIT(48),
  returns 52 bit address when an addr hint is passed
- riscv uses a DEFAULT_MAP_WINDOW of BIT(47) but only uses
  it for allocating the stack below, ignoring it for normal
  mappings
- s390 has no DEFAULT_MAP_WINDOW but tried to allocate in
  the current number of pgtable levels and only upgrades to
  the next level (31, 42, 53, 64 bits) if a hint is passed or
  the current level is exhausted.
- loongarch64 has no DEFAULT_MAP_WINDOW, and a default VA
  space of 47 bits (16K pages, 3 levels), but can support
  a 55 bit space (64K pages, 3 levels).
- sparc has no DEFAULT_MAP_WINDOW and up to 52 bit VA space.
  It may allocate both positive and negative addresses in
  there. (?)
- mips64, parisc64 and alpha have no DEFAULT_MAP_WINDOW and
  at most 48, 41 or 39 address bits, respectively.

I would suggest these changes:

- make riscv enforce DEFAULT_MAP_WINDOW like x86_64, arm64
   and ppc64, leave it at 47

- add DEFAULT_MAP_WINDOW on loongarch64 (47/48 bits
  based on page size), sparc (48 bits) and s390 (unsure if
  42, 53, 47 or 48 bits)

- leave the rest unchanged.

       Arnd

Powered by blists - more mailing lists