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 E8304ECE564 for ; Tue, 10 Sep 2024 09:14:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 588018D0038; Tue, 10 Sep 2024 05:14:26 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 537CD8D0002; Tue, 10 Sep 2024 05:14:26 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3B1378D0038; Tue, 10 Sep 2024 05:14:26 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 1EE588D0002 for ; Tue, 10 Sep 2024 05:14:26 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id A527AA12D7 for ; Tue, 10 Sep 2024 09:14:25 +0000 (UTC) X-FDA: 82548267690.19.78FF6B5 Received: from flow3-smtp.messagingengine.com (flow3-smtp.messagingengine.com [103.168.172.138]) by imf04.hostedemail.com (Postfix) with ESMTP id 7976B4000D for ; Tue, 10 Sep 2024 09:14:22 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=arndb.de header.s=fm1 header.b=gDz+28Ep; dkim=pass header.d=messagingengine.com header.s=fm1 header.b="r Wap/EB"; spf=pass (imf04.hostedemail.com: domain of arnd@arndb.de designates 103.168.172.138 as permitted sender) smtp.mailfrom=arnd@arndb.de; dmarc=pass (policy=none) header.from=arndb.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1725959610; a=rsa-sha256; cv=none; b=tXribGWGLpQEEcmeCOK1xXtr6j9PSUPjBnSo/iffpcX3i+y00vVDlLDrnnEs8xLMJGSUsG MOIwhyq5TwOBlIbzaLKRt3HHOJkCBUo9UgYkppbPlh8JrT5iUU2vKKzhOk/7esz5v/Wchd 9lSXsdYbH9RpkDzVjcYykFENf6kVxYQ= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=arndb.de header.s=fm1 header.b=gDz+28Ep; dkim=pass header.d=messagingengine.com header.s=fm1 header.b="r Wap/EB"; spf=pass (imf04.hostedemail.com: domain of arnd@arndb.de designates 103.168.172.138 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=1725959610; 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=0bAs8GYS7XnporkOcRS5T4HRjTKpKe/QReainQI38Rk=; b=GDdu0mUo0J3vbE5saqBN/ah5vSv7CCKf+2at5hpYH3R9+zmY1A1O/8eRXQmR2r/mXpoSCD eKAlOxFylqn2ie7yuxbKMwLidgLb45Dp0v2Y5uPb0Sa6OWvQ2j2Vsr+b53uOuJx+C/PXqH FbUZJkXhJw7HjBRmQCNfOxBK04w5TfE= Received: from phl-compute-10.internal (phl-compute-10.phl.internal [10.202.2.50]) by mailflow.phl.internal (Postfix) with ESMTP id 72BC5200351; Tue, 10 Sep 2024 05:14:21 -0400 (EDT) Received: from phl-imap-11 ([10.202.2.101]) by phl-compute-10.internal (MEProxy); Tue, 10 Sep 2024 05:14:21 -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=fm1; t=1725959661; x=1725966861; bh=0bAs8GYS7XnporkOcRS5T4HRjTKpKe/QReainQI38Rk=; b= gDz+28EpjBqcJxXIpE07fsC74DAIbGxqo+wO/HvSw2cBjD0C4R6ZpUDaWI8whYgB Uou5tC2Ba2wAK+EqftPNq2n28JERnlqyobUzsSO7FOGcG9ZiHwpfeJASHNlk/d4X 5WiSttpIB5Eir9pgs0kvpEK0oEXGwRcZGRDrgUdP8vFhxfezO3ZRebg6KxQY8DB+ Uhf5KhhI6mL50jLO0daKWiHfpjmqkQas8EX/yg3llN0VUKg/Stthb0rDw6zcxqPY hlQQwIDg5uokWvMGZ5nIpVqoej/xmK+OuzWbc01t+AIEgASbJhDVMG1M0JMEeFDW 72pPfdCEMdc8thjma5PNPQ== 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=1725959661; x= 1725966861; bh=0bAs8GYS7XnporkOcRS5T4HRjTKpKe/QReainQI38Rk=; b=r Wap/EB3CA7vwicHILWXH6WMegg0FjR1Y0PbkSlHz6bdN930Oik8Wzk0mX3oX3Dcf mgJex09u2n+JG/FORnOd62+EaW184geOkclWYSUlgQn8nU841vhkp+eh4R+ZLYk7 DrXAGb6hkGTp5ublWeGD9m4c/xVj/Mak9mwuU7MvtygsYDeDF+kcsBRlQbRYQPY8 fUF+xTxPfulNUbAFbGAzpDkalWbBpwaOe3FDeFX0A25/64tjJrpUw5GkeufjRD7V NNqgO+ua3k+FdgEB7he2co98A/HrB++MPt6MD+fMHIqTQJpQcTBj2Aey7tX4yR1y Qda9OdbsMwbeGeP9pgQAw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrudeiledguddvucetufdoteggodetrfdotf 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 02253222006F; Tue, 10 Sep 2024 05:14:18 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface MIME-Version: 1.0 Date: Tue, 10 Sep 2024 09:13:33 +0000 From: "Arnd Bergmann" To: "Charlie Jenkins" , "Lorenzo Stoakes" Cc: "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: <89d21669-8daa-4225-b6d2-33d439ebd746@app.fastmail.com> In-Reply-To: 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> <7be08ea9-f343-42da-805f-e5f0d61bde26@app.fastmail.com> <016c7857-9ea8-4333-96e6-3ae3870f375f@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-Stat-Signature: brqtbqwy4p5zbnhck68o7aa3eyziouuy X-Rspamd-Queue-Id: 7976B4000D X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1725959662-526468 X-HE-Meta: U2FsdGVkX19oBfNlBrk+Fk1V9jq1O5Ih096x+YZzieTFZ/VHa5IQ4vnZMtiQppmhnXJNaLUAFDbJgqOA1Gtw9casYBmAHPqOtm/Lji4sUfV7ak4dcSPygzMDk7sFVkD+lE31/8ToJIhr0BiYatJTmxJMb56UW5A33Q5br5UhZY8JIc9zEFYDQPHGtQmn7ZS928yOvDB5WmlwCE8fv6u6Tz7vJOLk4KnBTyYqlkLx0SBu9FAQBB05ElT5o2P1QHGb5+3kMEDfzwXY0BGhk/kwRKROgDZbdl2DDjd61Zm6EyTVuVcIMxheSyy10MpjMzwrZZJxaz1kQHph1VHYMoVlAmtPrZwIVPPcsk6eMdLf7FbnFk29M+ENRgMaGWvSBF/FBi06zFvy0w391pzkBHF/zEGzhwWGmMEFrOqnEp42f1YMOF7K4rks9NGLiO4kIAkjvib7PgXKBDMzi3pkIqL2aHjhXlgSfftyZQtX2NVCwYxDZwj/OTIPUC3bP3mPBZwjS5NmOg+Ff7ioqiBKj8/c6o41gFLmk4YnFZ2m+JfmMhKdbbfYwcxFqG3ZgQbJNUAnskpIjO0AEj3zguBZcOeUWjmmAPiOcV+LtyspW5680dyiGXhISq5Ju+bHzC+O3oPVtYRITCIPgdt4AlFyvGiImSRdC3EwrzVZpils3+4Nme7LsOjq1jGo8MhzQLMHIEuH5LHfOKnOuXriLOSKeYhObak7rRr12sMzyoRcyrY97PBgrkwTtYKQMsfaaDiAHFPcIdFd9Km1Sykw+SF+LTuzKNrcTSAiTG4/Pxx+vfMtqBBxte/vLCUoFjw+PLSRsnZDgv6h81zw9ZCvCFqBySBp0P6uVBzyE9B55ailUaXOssumx5AmNKCyfZZ2CUz6tGcdDy+PKzzmUu4fGqkE4TyWyRdm6aANouFbOqebrNrO+E0py4Dhsy+yxK6uMYYYK3LcRdQRAgNgXtId5ikDX1Q U+3MW50W uOGvYyQGw2jDbqD6fKmsztIkCEmUHlANezSl7Gj4SbqJbeP5vPl9Km/3jTQRh59/dD0XamymehiWdmppQAOLcPsb9BP84k4EuXCzr30ablJlS0FJV7tqzt3hzzmAs0Vr6H/NQxKPjpi9BEyt/TFC2CdPb9sE5c5tMxYM8Q02g3IS7iu3k9dRaon2Y4K/RPpBeqT78uVHs+qN7OmD4OidWs2S/OvdK3Xl6F66gr30JJHsBCxkzp3Ap3ukc4r5ro4As8nZ3KuIATeZEC3UBil81bgl78wg3bqJn0frKWIkupO2c0LU= 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 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