From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 42BABCE7AF1 for ; Fri, 6 Sep 2024 09:14:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 715BD6B007B; Fri, 6 Sep 2024 05:14:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 69E416B0082; Fri, 6 Sep 2024 05:14:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4F0BB6B0085; Fri, 6 Sep 2024 05:14:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 2DF266B007B for ; Fri, 6 Sep 2024 05:14:36 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id D89AB1410AD for ; Fri, 6 Sep 2024 09:14:35 +0000 (UTC) X-FDA: 82533752910.03.8C97A0B Received: from flow5-smtp.messagingengine.com (flow5-smtp.messagingengine.com [103.168.172.140]) by imf05.hostedemail.com (Postfix) with ESMTP id C63A7100008 for ; Fri, 6 Sep 2024 09:14:32 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=arndb.de header.s=fm3 header.b=qSNYokqu; dkim=pass header.d=messagingengine.com header.s=fm1 header.b="G P0u48y"; spf=pass (imf05.hostedemail.com: domain of arnd@arndb.de designates 103.168.172.140 as permitted sender) smtp.mailfrom=arnd@arndb.de; dmarc=pass (policy=none) header.from=arndb.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1725613975; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=HqqZZ6TfA9de4ir05q0Y8WhAGkTcX7yt1g8RzTkpSrA=; b=KMq6Iax8rcFcchGsRMcNMLfEfIg1fqt876PUw4ZLtSneBU4noBzUPpu/PCJd7DJOxaEDe6 orGHibsZG4U2zU1NWlHXXiiZtGED43sp291AQKo5euSb2420Oe4EAcsStGjc9vhtX73mjj 6rZJnsw+t1Xf+pNWM0XcCj0rc9hsCEw= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1725613975; a=rsa-sha256; cv=none; b=PPHMuePXlL+8OBd6av0bTcJtUV5fu6nnGaQfdFy/4F0AECZJx/OGXifM1X2sbWMnoAN7wh pi6QhHKSBzl58uMFxyPzVMw1lajbbqw4tKTMbasojBCyGk9WJlpmnr0SKnNykdprhoFvsB 2R2eI6v/hkiFRuAFhMJAh7U5sYpVK1g= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=arndb.de header.s=fm3 header.b=qSNYokqu; dkim=pass header.d=messagingengine.com header.s=fm1 header.b="G P0u48y"; spf=pass (imf05.hostedemail.com: domain of arnd@arndb.de designates 103.168.172.140 as permitted sender) smtp.mailfrom=arnd@arndb.de; dmarc=pass (policy=none) header.from=arndb.de Received: from phl-compute-10.internal (phl-compute-10.phl.internal [10.202.2.50]) by mailflow.phl.internal (Postfix) with ESMTP id DDEA7200175; Fri, 6 Sep 2024 05:14:31 -0400 (EDT) Received: from phl-imap-11 ([10.202.2.101]) by phl-compute-10.internal (MEProxy); Fri, 06 Sep 2024 05:14:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arndb.de; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm3; t=1725614071; x=1725621271; bh=HqqZZ6TfA9de4ir05q0Y8WhAGkTcX7yt1g8RzTkpSrA=; b= qSNYokquTBb36v/l2H+5umTZJpjnq4aypJ/npxpzHmDdxBDZ1Fxf8dUNOmMkRFA1 YXybRlGR2AZy4RgwNXAktBgant6gRKCjXuQ/Bvwy7XoLfGCi3yJ8afo4cstP1uXY BMM6hndRke9GmnlOkrCMNLsFNmZm28J17yqN1sYaV7uvXoOt2clukefCVWe5q57x +IoAM+9epy+YDnFO9xuu7p22MvIZ+6+elSsFVr5cigUC+KeXJx9tNME+Dkv5YIT9 jtkK+jaXGmIw0PrzBLCS27eUdiIAeIxJ7A+gunA9b/4hXvpjB65PvKrSoSkZsLue SJupCGJVUseiWtWwWes1jw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1725614071; x= 1725621271; bh=HqqZZ6TfA9de4ir05q0Y8WhAGkTcX7yt1g8RzTkpSrA=; b=G P0u48yY13W+zNvKQlBemH/22HdGBDJ67Vgk51dvta0gc3WKYa5pc4AyiRK4VqGpb YW8vfxfHI5BPqtTBmISn2BHVcF7nfhib7BFIlMddw8S+zScfxauirBva4TPbloWP l9p5UYW/hoQqqZXHZEHtkWbwdQiyqzzgXZIZKjLP6t4KEA1kyxnb96Nl7Z2U03Kn CwOrrVmSUlerPWhcj9p0VhbNBqsOhsfAEruNjSMiVt1FQdR8S8VanLAF7I/TT2XJ SI1tW1fea/gPn7Bg86agsvGPFEj6KA43twP1r2F/Hl9gonTAKDpMEhShfUEOzQ4e 3LvQecbBtSoS8en2fx8yw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrudeiuddgudefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh htshculddquddttddmnecujfgurhepofggfffhvfevkfgjfhfutgfgsehtjeertdertddt necuhfhrohhmpedftehrnhguuceuvghrghhmrghnnhdfuceorghrnhgusegrrhhnuggsrd guvgeqnecuggftrfgrthhtvghrnhephfdthfdvtdefhedukeetgefggffhjeeggeetfefg gfevudegudevledvkefhvdeinecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpe hmrghilhhfrhhomheprghrnhgusegrrhhnuggsrdguvgdpnhgspghrtghpthhtohephedt pdhmohguvgepshhmthhpohhuthdprhgtphhtthhopegsphesrghlihgvnhekrdguvgdprh gtphhtthhopehtshgsohhgvghnugesrghlphhhrgdrfhhrrghnkhgvnhdruggvpdhrtghp thhtoheplhhinhhugiesrghrmhhlihhnuhigrdhorhhgrdhukhdprhgtphhtthhopegthh hrihhsthhophhhvgdrlhgvrhhohiestghsghhrohhuphdrvghupdhrtghpthhtohepuggr vhgvmhesuggrvhgvmhhlohhfthdrnhgvthdprhgtphhtthhopehmphgvsegvlhhlvghrmh grnhdrihgurdgruhdprhgtphhtthhopegrnhgurhgvrghssehgrghishhlvghrrdgtohhm pdhrtghpthhtoheptghhrhhishdrthhorhgvkhesghhmrghilhdrtghomhdprhgtphhtth hopehmrghtthhsthekkeesghhmrghilhdrtghomh X-ME-Proxy: Feedback-ID: i56a14606:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id 84B61222006F; Fri, 6 Sep 2024 05:14:29 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface MIME-Version: 1.0 Date: Fri, 06 Sep 2024 09:14:08 +0000 From: "Arnd Bergmann" To: "Lorenzo Stoakes" Cc: "Charlie Jenkins" , "Richard Henderson" , "Ivan Kokshaysky" , "Matt Turner" , "Vineet Gupta" , "Russell King" , guoren , "Huacai Chen" , "WANG Xuerui" , "Thomas Bogendoerfer" , "James E . J . Bottomley" , "Helge Deller" , "Michael Ellerman" , "Nicholas Piggin" , "Christophe Leroy" , "Naveen N Rao" , "Alexander Gordeev" , "Gerald Schaefer" , "Heiko Carstens" , "Vasily Gorbik" , "Christian Borntraeger" , "Sven Schnelle" , "Yoshinori Sato" , "Rich Felker" , "John Paul Adrian Glaubitz" , "David S . Miller" , "Andreas Larsson" , "Thomas Gleixner" , "Ingo Molnar" , "Borislav Petkov" , "Dave Hansen" , x86@kernel.org, "H. Peter Anvin" , "Andy Lutomirski" , "Peter Zijlstra" , "Muchun Song" , "Andrew Morton" , "Liam R. Howlett" , "Vlastimil Babka" , shuah , "Christoph Hellwig" , "Michal Hocko" , "Kirill A. Shutemov" , "Chris Torek" , Linux-Arch , linux-kernel@vger.kernel.org, linux-alpha@vger.kernel.org, linux-snps-arc@lists.infradead.org, linux-arm-kernel@lists.infradead.org, "linux-csky@vger.kernel.org" , loongarch@lists.linux.dev, linux-mips@vger.kernel.org, linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, linux-sh@vger.kernel.org, sparclinux@vger.kernel.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org, linux-abi-devel@lists.sourceforge.net Message-Id: <7be08ea9-f343-42da-805f-e5f0d61bde26@app.fastmail.com> In-Reply-To: <58f39d58-579e-4dd3-8084-baebf86f1ae0@lucifer.local> References: <20240905-patches-below_hint_mmap-v3-0-3cd5564efbbb@rivosinc.com> <20240905-patches-below_hint_mmap-v3-1-3cd5564efbbb@rivosinc.com> <9fc4746b-8e9d-4a75-b966-e0906187e6b7@app.fastmail.com> <58f39d58-579e-4dd3-8084-baebf86f1ae0@lucifer.local> Subject: Re: [PATCH RFC v3 1/2] mm: Add personality flag to limit address to 47 bits Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: C63A7100008 X-Stat-Signature: 8cxgy34mie6nrmu94hphfwixba8gbz7z X-HE-Tag: 1725614072-900849 X-HE-Meta: U2FsdGVkX1+F8xArcc9YiX479oRlXka0WIJG2F6PmF3Qhp0PAyT0ON+ziWijcTO/Q0Y6jCeyuSM/9jgjlC53F0JY+PmJaH21q+2Na2J6TFg3JgiHA+ebADDWvowiDRegc116uHzAiBELFE/JzGkD1HTmJ6zGHrqqdOzLh38ydgHH0H39Ba0Rio15gaYwz2RuPeQoVtXgPxdU6wMFxnpqi6vX4+YdE8fEgFQX6TQiqNRHlNCm5w7zLQmaRalceyY9GGO53XcBktmOfUjTyNFqv2wapX6eeUYtOvpG7iE4bmzT0R/krqxHlwo/W4WW0Mx45KKuyVNqGzg6X7j6vQ9XwAF1RYSByW5YNBnu7GdkpWa+AC3x3aW3+IhY3MQIZcJc2QrBGLWeIcPmrCziqOad8Mk/nFJUTZK528KDDW/XyilBmNBrWIW7g93EvJq54jpn4FwXaN2N8vY2LIzsymKKlSPG98g4FnnwxUTjuN8hCTMf6v2Fh/8IPTySZ6vK/wRUV0B5FkcuWpdDmSUDoKqg8Eyt8YZw5KeBLsjtvlkysuEUTOw9gkxHQLsYBXJi3zDaNVjRfRTMTcLRdxa6chSwecBxYz91xDep7EKnHQ41JueHsKepGwQoRAHr45FkA9Y6Oe3/Ll1rp04s8IKSYTmT4EC3fCVHtqNjLgXPaEBiBcExNB0LBMW4BdjOUFmzJCvQL7WdT7Lirx//o38CQZ2DrugyYdBrf0lQCGO1cmMN6F2dnoHQa40xoROtOVEZvwhvNAOPly1IV8padRb2VP9ozMdpmGMBhE1hgzBkX5TUX6loHHUIS8tohWG7/STQPEwUYnn/TasLTcb/txKkErwWd7zcKpz3uhXJOlcUE6H8fRHsJF08D37uD2PViYPgB8KLXqpwZ9YH+z4KQKkS6Pch+BoOaMF8IvCkGdIXaNUz1pPZw+oFdT9+1Wpz6f0zqqvzsKJW05u00+QbZbBZh83 vsUT6c3l VlYFsZZ9s+DYK10e90/ckHhNQ9X7BRGlYIxupX3TNf1GXJbZXoD8+LBvFyGREKJF5qZNqHegs4D2U3VWUuY1Z4TP9NAwAKanUujBOliafX5kwIPXeNfELfdduFremAcneXqnILk0WieYNvcI0X1xm5QcVESJ1wZ3vkquGN6iDm+U2ROzuA6T4Ny5hjdG8DLIf2HYLPuaEl5e2nKCvEy3GmgQ5Wrfa3ZKbMELA7wVQHe8baULb8outLlMVr1CDI9F3h261FuZvWPOKHETM3pCyHbJ7sfSJpyCRpdTyFQp2MkHHsfr5rJNIgEge90ROb+PTA1HAHuagrbwfBNtYgF3Tp57miwCyb627zJ0Da3Ugv+BDMumLlqk37RlRNR4B/2dgSPsH0J/5VId0RFmS18lRjYOfbrEO9OTzaYTtxme68WlVThHpN2kaDqTWpQ== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Fri, Sep 6, 2024, at 08:14, Lorenzo Stoakes wrote: > On Fri, Sep 06, 2024 at 07:17:44AM GMT, Arnd Bergmann wrote: >> On Thu, Sep 5, 2024, at 21:15, Charlie Jenkins wrote: >> > Create a personality flag ADDR_LIMIT_47BIT to support applications >> > that wish to transition from running in environments that support at >> > most 47-bit VAs to environments that support larger VAs. This >> > personality can be set to cause all allocations to be below the 47-bit >> > boundary. Using MAP_FIXED with mmap() will bypass this restriction. >> > >> > Signed-off-by: Charlie Jenkins >> >> I think having an architecture-independent mechanism to limit the size >> of the 64-bit address space is useful in general, and we've discussed >> the same thing for arm64 in the past, though we have not actually >> reached an agreement on the ABI previously. > > The thread on the original proposals attests to this being rather a fraught > topic, and I think the weight of opinion was more so in favour of opt-in > rather than opt-out. You mean opt-in to using the larger addresses like we do on arm64 and powerpc, while "opt-out" means a limit as Charlie suggested? >> > @@ -22,6 +22,7 @@ enum { >> > WHOLE_SECONDS = 0x2000000, >> > STICKY_TIMEOUTS = 0x4000000, >> > ADDR_LIMIT_3GB = 0x8000000, >> > + ADDR_LIMIT_47BIT = 0x10000000, >> > }; >> >> I'm a bit worried about having this done specifically in the >> personality flag bits, as they are rather limited. We obviously >> don't want to add many more such flags when there could be >> a way to just set the default limit. > > Since I'm the one who suggested it, I feel I should offer some kind of > vague defence here :) > > We shouldn't let perfect be the enemy of the good. This is a relatively > straightforward means of achieving the aim (assuming your concern about > arch_get_mmap_end() below isn't a blocker) which has the least impact on > existing code. > > Of course we can end up in absurdities where we start doing > ADDR_LIMIT_xxBIT... but again - it's simple, shouldn't represent an > egregious maintenance burden and is entirely opt-in so has things going for > it. I'm more confused now, I think most importantly we should try to handle this consistently across all architectures. The proposed implementation seems to completely block addresses above BIT(47) even for applications that opt in by calling mmap(BIT(47), ...), which seems to break the existing applications. If we want this flag for RISC-V and also keep the behavior of defaulting to >BIT(47) addresses for mmap(0, ...) how about changing arch_get_mmap_end() to return the limit based on ADDR_LIMIT_47BIT and then make this default to enabled on arm64 and powerpc but disabled on riscv? >> It's also unclear to me how we want this flag to interact with >> the existing logic in arch_get_mmap_end(), which attempts to >> limit the default mapping to a 47-bit address space already. > > How does ADDR_LIMIT_3GB presently interact with that? That is x86 specific and only relevant to compat tasks, limiting them to 3 instead of 4 GB. There is also ADDR_LIMIT_32BIT, which on arm32 is always set in practice to allow 32-bit addressing as opposed to ARMv2 style 26-bit addressing (IIRC ARMv3 supported both 26-bit and 32-bit addressing, while ARMv4 through ARMv7 are 32-bit only. Arnd