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 54E60C8303E for ; Thu, 29 Aug 2024 17:33:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 44E286B00A6; Thu, 29 Aug 2024 13:33:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3D7236B00A9; Thu, 29 Aug 2024 13:33:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 229E46B00AB; Thu, 29 Aug 2024 13:33:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 0406E6B00A6 for ; Thu, 29 Aug 2024 13:33:32 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id AC41F1A1232 for ; Thu, 29 Aug 2024 17:33:32 +0000 (UTC) X-FDA: 82505979864.19.B95FF05 Received: from mail-pg1-f175.google.com (mail-pg1-f175.google.com [209.85.215.175]) by imf08.hostedemail.com (Postfix) with ESMTP id B5245160008 for ; Thu, 29 Aug 2024 17:33:30 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=rivosinc-com.20230601.gappssmtp.com header.s=20230601 header.b=Qdu8AahU; spf=pass (imf08.hostedemail.com: domain of charlie@rivosinc.com designates 209.85.215.175 as permitted sender) smtp.mailfrom=charlie@rivosinc.com; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1724952722; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=ShOV+xhv6/I7AhDzzz24YoQnvepxBGugrDU9V6pmXjY=; b=POCMYGsK5Q0wRGLpwePXV4AOPk8MDvp+JAuVitNwSIn5zLBhtBHcVgLa3sC0uRb7cl1Ppy KbzgkA4rqXytn80zfUcC4eSYkZ3nbD5x4t9xONf/4NyWeQlzwTEKj+rWg2b5MaEJXb5VKq H6RT0xoCM8JbAHyGO0njsO8CdbHo0i4= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724952722; a=rsa-sha256; cv=none; b=ZYoFqm8SiNRqiuXaDHSb5nQQbFX8AkQcDbHe2MeTUPlUBVABpwxehArrXH7pFZ077qV3an E+dfwzNV7rp9kXmlSHufvP90WpD3Q2XCXsYMT3aNMwKHdgw8JmGuT1PLLQCqfEJCsCf2iM Fa0ufrVdGgnEBjCHeptNGaEKxnPShaI= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=rivosinc-com.20230601.gappssmtp.com header.s=20230601 header.b=Qdu8AahU; spf=pass (imf08.hostedemail.com: domain of charlie@rivosinc.com designates 209.85.215.175 as permitted sender) smtp.mailfrom=charlie@rivosinc.com; dmarc=none Received: by mail-pg1-f175.google.com with SMTP id 41be03b00d2f7-7ae3d7222d4so627505a12.3 for ; Thu, 29 Aug 2024 10:33:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20230601.gappssmtp.com; s=20230601; t=1724952809; x=1725557609; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=ShOV+xhv6/I7AhDzzz24YoQnvepxBGugrDU9V6pmXjY=; b=Qdu8AahUvaBOHu1aaXxGh8nEQRRSCRKN17aV7TNEmWejJk8lLxm8nxDueUV9GGVUrD TBfzsmpmE+KeroaNmUp2wJpZ93LMJYZvX6m2PXI2Kprlb0VpOdyYima5ccWLIKPDMAsK Bw9HtDgjh/bxfqap9IBVS14BSYux0A4+mChRS32dBm/cv1YHSswcUJFM0qslIC7OBSZv RI8YuEYg2aaooCU3QGGWWG0z3Eg+xPaSGHepE867T3phS9JNQ7Kp4FsrLnZXPeMYtylL Ll3x8kHYB/lJjAURFkhDMP4NIljJ7dlWKeXMxqgXKk04/Gt34QRuk/LiVZmBOrMw3W+D 0nUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724952809; x=1725557609; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=ShOV+xhv6/I7AhDzzz24YoQnvepxBGugrDU9V6pmXjY=; b=K4qqVKw1xU3Jy/o4VvFvwOw3ui2QOVkU/dEevSIynbma1/ZAPWkYX/3bCB2dxu/i45 ZdyA2ywJZMI3oJb5LRYlvd+KWn2aIUG1AEcMUMDgtCY3PBBtGDCXTBQ9mEX5/aUv5QDI AjVTTiXQpaxyPV0oX2wM2v4Z/F7mkiihQSc8MODRTBnDMvhyVuN3dgskfhvp+SLvqzDM L/v8Q6CYNPMsVfbKDm0t2Up3w29OiZ7MNbmOlEFtFF5Ym9mSqQVzRoVyrZoz5lmytC78 P0PJbKwjjG2/sQeFHej62mdx5tnCDEDUOpEp4Bljx++suyNtz0zL3erULMw4ITKyBq3d QDNQ== X-Forwarded-Encrypted: i=1; AJvYcCVWWFz0vFsMI0RHsO7x44V4eOLKkZsanjWFbRtwnbxL8Z2ZktPsyTQQSD75GDToi6HFYsjAT9FQyw==@kvack.org X-Gm-Message-State: AOJu0YyD9hRNh2nzyjEy20aNS5sXgmNN6TwDWuE0YHvnPNhq4MFOldsK DNmNXRwFBScyu0FFxo2daK85DXFj4X2BiC7t2euTMUbH/r52uRCl1SlbNJUxXFY= X-Google-Smtp-Source: AGHT+IEMMPSZiUHtBfNuQb92KkzHdlzWvSIVDrDVVbnqmIDING28StXdegl4Q9VHUGwvTGBDq12VFQ== X-Received: by 2002:a17:90b:524a:b0:2d3:90e1:41c7 with SMTP id 98e67ed59e1d1-2d85638414emr3575500a91.31.1724952808963; Thu, 29 Aug 2024 10:33:28 -0700 (PDT) Received: from ghost ([2601:647:6700:64d0:c81:fe51:78cb:fc02]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-2d85b0fdf44sm1949050a91.6.2024.08.29.10.33.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 29 Aug 2024 10:33:28 -0700 (PDT) Date: Thu, 29 Aug 2024 10:33:22 -0700 From: Charlie Jenkins To: Michal Hocko Cc: Arnd Bergmann , Richard Henderson , Ivan Kokshaysky , Matt Turner , Vineet Gupta , Russell King , Guo Ren , 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 , Lorenzo Stoakes , Shuah Khan , linux-arch@vger.kernel.org, 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 Subject: Re: [PATCH RFC v2 0/4] mm: Introduce MAP_BELOW_HINT Message-ID: References: <20240829-patches-below_hint_mmap-v2-0-638a28d9eae0@rivosinc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: B5245160008 X-Stat-Signature: mqe84zqkppsuwdswb43r635ky9auajm6 X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1724952810-387379 X-HE-Meta: U2FsdGVkX1+wNTG/qwmfYctBBo27HtTt47zCEYjEjukB/9wKGAMTDLVHl8aSxd35SQpfcK4Aur2ILdV9bdSesTL7NU9ADUSmeeQkvTN9F4UMTG277vnUT/VjA5FjghpkjonvD3wCjbtLhYllzfQlOMQkK7y4Oh/cCAKvFDd+Xbwo3cqGFw2yaP5eG/mkwv2FqqSotW0FChCzrN6KgiyWxjCAY/rkH9o6gVDvivQdEN0MrN3jSk9C74ZUSoZoqqDw3ij7m9p+u7ctALa53+xfLeb2vN6O2LGHSccn2QrhRrdBd/LE5uGOGAxXwECQIXHNMrCDnWNPxYXTU5m4IGK1SEWvppOD51fFM9q1N8jijsNfQuiLbHvaerHEFu2vCBZ6ZyOe2aM+5OHgL/nUeYU2AJPWCLLpR2oCS9KHD1b9mMaLKr+vrgaF98ncqgECErWn1ibaNIWGn5i6YxwBfIPNEok72P7ngPNlMZw9rCRgeuLwfkMZ54R/PL7Et/aouO4AdvOXZVgMxvNSdnFH95n/6gafaIjktPwvHjwhLV0REji1Oq2DCPGAGk9vtwejn8JnKu5eN1Jn8e3m3evHEKMQ0Bu4CpavLhBFfwK2VIAXp4SioF5JIPFictKGffPhgJ9Bx4qFp47w55jB1gRT89vHkLH1KMJWCa5gmfBcD/5aGYLil1w6+1BLh0I5lpoU13ytiwC63l4paZ+FybSrjb/qrZzYMrZp9Yk149KBZiP5OaRKzoFb2S7bt0bPFA02EN9UW4+HfZFcDbqL2O2aTlvw+PUUGUa3RtY1bMUjjSHIrEGiTGlEpCTgbPZYjdbLe0nQ4PjpU6e+bpgB5YD+UJSfmQ9w/koGDQXKtApEN/OHSikYtC2HfuPzjNMnWG8JX2vzrTpDGSrXnJRDNXZ+8b2aaF3xh70OxAyfwAlfmnDXSlEOILRCAasqCnGxUEvgHKD5UfiNu/FOskD+PxgzLpj WdrxqXAU 2CjnXI3egbxtuywXJeCyDQjUvB1u5bDqSJFQk5ZRB4C/gZ22d/m/gtJLn+v2G4+QC/DUTH5v4LIFFxyLz77aqXfkM9TWnmhPxrD53sek3Jzeeh1myynRxe6z95soDGxAprUWL5a2EHxBDkCCAZWlaWL8kO32KLx66yFbnD8/GCr5TnvqXNQNYHbr+C1glrRJWAMCCnsUdzkdkS6NYqpEoTfR14o+5h9eSfGARlJT9OapDRt+fTlunQA0PI+0Fk5JcI5zrEE5/0wL5ywAznSCithHf0udpKpYxumP9/j7l1H1lvr4n/josra99TGpESt+TcvbdrbNz9aOmoisVEEffFTS/BPdQtssa8KqU9Fc4ineE78JckzYx44TV/ycaRlRlNBvNcGKfzC/pXxrm/xytzKUPJdBXROAaddMhTef2SZwV0/7nEIMivqVGgku+AwFn7C8b5VtQ45rkg79nMzrzjqGymos0g4+becxAOuqhoOXsFKcGygqccHdfx6R6SFfYhqy85jBa0UTsoTmiLt5VoH8yDcOWoZ/IphLIOWGqHjFVv02jFG8QLxtzbcUTB2ncS/EXqtBuD3wSK0ms41pv7QMEBxeB6dm4QN7lYYqv8yiMlJw= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000002, 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 Thu, Aug 29, 2024 at 10:30:56AM +0200, Michal Hocko wrote: > On Thu 29-08-24 00:15:57, Charlie Jenkins wrote: > > Some applications rely on placing data in free bits addresses allocated > > by mmap. Various architectures (eg. x86, arm64, powerpc) restrict the > > address returned by mmap to be less than the 48-bit address space, > > unless the hint address uses more than 47 bits (the 48th bit is reserved > > for the kernel address space). > > > > The riscv architecture needs a way to similarly restrict the virtual > > address space. On the riscv port of OpenJDK an error is thrown if > > attempted to run on the 57-bit address space, called sv57 [1]. golang > > has a comment that sv57 support is not complete, but there are some > > workarounds to get it to mostly work [2]. > > > > These applications work on x86 because x86 does an implicit 47-bit > > restriction of mmap() address that contain a hint address that is less > > than 48 bits. > > > > Instead of implicitly restricting the address space on riscv (or any > > current/future architecture), a flag would allow users to opt-in to this > > behavior rather than opt-out as is done on other architectures. This is > > desirable because it is a small class of applications that do pointer > > masking. > > IIRC this has been discussed at length when 5-level page tables support > has been proposed for x86. Sorry I do not have a link handy but lore > should help you. Linus was not really convinced and in the end vetoed it > and prefer that those few applications that benefit from greater address > space would do that explicitly than other way around. I believe I found the conversation you were referring to. Ingo Molnar recommended a flag similar to what I have proposed [1]. Catalin recommended to make 52-bit opt-in on arm64 [2]. Dave Hansen brought up MPX [3]. However these conversations are tangential to what I am proposing. arm64 and x86 decided to have the default address space be 48 bits. However this was done on a per-architecture basis with no way for applications to have guarantees between architectures. Even this behavior to restrict to 48 bits does not even appear in the man pages, so would require reading the kernel source code to understand that this feature is available. Then to opt-in to larger address spaces, applications have to know to provide a hint address that is greater than 47 bits, mmap() will then return an address that contains up to 56 bits on x86 and 52 bits on arm64. This difference of 4 bits causes inconsistency and is part of the problem I am trying to solve with this flag. I am not proposing to change x86 and arm64 away from using their opt-out feature, I am instead proposing a standard ABI for applications that need some guarantees of the bits used in pointers. - Charlie Link: https://lore.kernel.org/lkml/20161209050130.GC2595@gmail.com/ [1] Link: https://lore.kernel.org/lkml/20161209105120.GA3705@e104818-lin.cambridge.arm.com/ [2] Link: https://lore.kernel.org/lkml/a2f86495-b55f-fda0-40d2-242c45d3c1f3@intel.com/ [3] > > -- > Michal Hocko > SUSE Labs