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 E5F19CD13CF for ; Tue, 3 Sep 2024 08:44:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2E5628D0148; Tue, 3 Sep 2024 04:44:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 295318D0139; Tue, 3 Sep 2024 04:44:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 10F818D0148; Tue, 3 Sep 2024 04:44:38 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id E87398D0139 for ; Tue, 3 Sep 2024 04:44:37 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 93578A1296 for ; Tue, 3 Sep 2024 08:44:37 +0000 (UTC) X-FDA: 82522790994.24.A62F333 Received: from mail-ej1-f49.google.com (mail-ej1-f49.google.com [209.85.218.49]) by imf16.hostedemail.com (Postfix) with ESMTP id 82D05180003 for ; Tue, 3 Sep 2024 08:44:35 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=OBXVMcF0; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf16.hostedemail.com: domain of mhocko@suse.com designates 209.85.218.49 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1725353006; a=rsa-sha256; cv=none; b=jCTZw2WuETp6fzUHKT8/8xhUz4B/g0rRV6en7JquBPPicdg9d+2ql/Vrc/IWcAO+HLtGWY HD5mfVUOUc9E9kuAjJGJHAjlHicFji5KkPIfsEZ7yyK3jGm63vd7XVv47p5bf6Cl0wQjA6 tadEdxH06qFdlVofBHrJWfQ1ZYq1FpU= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=OBXVMcF0; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf16.hostedemail.com: domain of mhocko@suse.com designates 209.85.218.49 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1725353006; 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=DZlZAQzsLSUE2kbM2Ozq+ZCTE7DVngzemuZ7Ob/TXXo=; b=3/KO1kGZQfm4p5wvq6Cs33+NYaeJ6W6IPC9AOHPIjKmRS46SYzthVlBVUUIWxldHRVH4MU 1UJwEQPkr/A/kXgE/G2vrC0x3I+WymKQCVpITyRUoF/IZlEl9VYTNInSQnRFqSrVTSWKXz M2mxTHpG5gb1ks9F48ULjX60E6pqK+Q= Received: by mail-ej1-f49.google.com with SMTP id a640c23a62f3a-a867a564911so594466166b.2 for ; Tue, 03 Sep 2024 01:44:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1725353074; x=1725957874; 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=DZlZAQzsLSUE2kbM2Ozq+ZCTE7DVngzemuZ7Ob/TXXo=; b=OBXVMcF0GtQ7KtDA9PeXkUw62ybIScCTZQ5mWQz/60ekKOx4GM2OfaecdiUvx0QCk4 lU3XWlsdc3Gs8Dfr7pqYq1AxPuUUeQnLwJhivsM4viCeEG1NB0Q4kp//XAyC5qahcNbn Zz63ve7e3dKyBXGnfvU4dwWJASwNQoJBIUFy8f1FLE6OFQSTh2W++JaqctvmPIDwffs0 nxhHhsIPPTGEhuaB+FkiLltW6iL7A/fgR35VHa//qd6iR08UF1MwI3+7NEVlEAOUteWx qhQK0YqYC942gE9U2s940Zw/2axjg4l+CmMTIkxc/EtWX0d3r6S8ChiHhgXGuJDzU1mi 15xA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725353074; x=1725957874; 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=DZlZAQzsLSUE2kbM2Ozq+ZCTE7DVngzemuZ7Ob/TXXo=; b=EgyJZ+no4qT5lxphPccqfOvpzfpBAt69L6ZpnuP9LF9MV56wSNdgESNkRyanGOkKfa pMfTHgWVwBgZy6HUXoaBl5J1XV8Agucwg9K7bTaNOKFm4R+vQbJF+1Re5FQNm4RllRh+ QF3xSX4JhWo7r476VEZzIqdoXe21KuzNolp0dkDu7xGFcn9icWESjlV3lVfBN3XG0olL VB3YogvPXhJNl1LHIJHZze1rCaRZ72aGcQpxD19YjD4313kd768FliMsnL8c7k6XsL7N QqOhTRAr3nIG7pKEXuFB0Hp741zBdsV4fZXaIfOcC0dt5yX3CzS1O838kSb8yW7mIxn8 +8jQ== X-Forwarded-Encrypted: i=1; AJvYcCXNQWZ1xMKwzUyntRSKW8Dxe2V6YlFUb58hPAd8NRTYDJ8WS1iQIq2P6aKv/O50AxWhUbxr9YjqAw==@kvack.org X-Gm-Message-State: AOJu0YxLOBsarKxBRkxMMdw/GyUy0KeoRaQytyx1pGIl3j09MTBjknLe tT1C8hqFPVrB3VGNmV87//HFbJ7vLh3EfksKX1uuqs/PMbOQOEnf5NnD/6r2uCg= X-Google-Smtp-Source: AGHT+IHxwo9IPQ3UzoYFwfDhkPsGqhCSjCzcHlJOoBuRWzF1gLxd2R9P128YTojI0aYfG8i4cNsStA== X-Received: by 2002:a17:907:2cc3:b0:a86:9058:c01b with SMTP id a640c23a62f3a-a89b9729542mr798530966b.65.1725353073684; Tue, 03 Sep 2024 01:44:33 -0700 (PDT) Received: from localhost ([193.86.92.181]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a8989221e15sm653868266b.193.2024.09.03.01.44.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 03 Sep 2024 01:44:33 -0700 (PDT) Date: Tue, 3 Sep 2024 10:44:32 +0200 From: Michal Hocko To: Charlie Jenkins 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: 82D05180003 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: s8beti8ee6yep5c4octx1mnn6tdhcdta X-HE-Tag: 1725353075-536495 X-HE-Meta: U2FsdGVkX1+Hsi5knfieswD1BSNUOsA/dKJRMdvIi1eFyKla4Ecft0TPwB6FnVPohB4ew+KbQAWKJidKRStP3vm3C3rLCIi6o2sn7WSdH8UKJEcSCA/E1eTkeYm2apfUeIeOWzdRza6oQh2HcBJi+7Q0x3eSRtpnmzBxk9tbSYXD68y2uEqBXN8REuOkCyKTCPLXAsDy03lDbCh2DWzbuD7Y4k4fYdlWDu5PaN/+p7+y4NneeHgxc0SEzcUuwpFr1Sw7PUPBGh1XC92GFLg680wG4SJ6vnQF6QTOn1zMixiSUq2OiN711gJhttP+LClEc6IdgOuLVu5S/eyC+ur5eNAQMydqNbwu1C88vJBwQhaIlHdk0U2o60SVfNqRNqT6RbbUmWtaqi+WmXfrmhi7X5aVp5xr5lJqbkiPmoD39RAzMytMqHOJy2og2v1x6I/5f2n/j0dGZPWwf5ZEUB33cLYlqnPGempF0e6G6p6t1HyKypEFZkf7VFEKp56BPK9344/kLQLu4EjGInlh/sZY73Cfspf/jQ9gjuuC+LJSqMOsjokdfqmiCulQGvrMkgJ97hg2odIVMzkeclK5BlGMiB/VawM6/e0un2ETsW+AwGjZqjCUfCP0kcAOUA4wzp5cTD58OFTQekwPL2xn3V32Sxy0sxEayj+gdPV86Ga1MJXa91TCf/jewk4WrN/Gn955Cux2FZAKJ4cHNJBh2do4z4mpTDosDKyk9p5ie7LBpPCAnGADIVkmtocDt8tv8IRLxhGdo3WAqoaSjfmQf4tUBJ/WHQeg+H4/O39/A2TdMD0qm/jIckCAzQbYNE8ccNIlXaVyqyF2Ebm9mAIbEqhtulvdX0StkFzEieqaU8Hr8ovogGwNPjOWXHP5lln0G421Mv28B6eS+Br+fqFitVjFF7l9e/yNFiAZVMbYcJxsZgXflJmW16LjWbHWCiJ6R84SGb49r7XtP74LSpdRu3t ucYilSIT VhJXfMBkEL0h0tvabfL7z9vLB+/L+FaLHQCGQy9Ss0lj025ugJ2iMeFA7+Bp8QnlsVz+j1Y6uU0rxNaL5YQ1YJTzVRz8kJefqZbtrw7juOyIaKrgJ/X1neWBgNea4Xw/rqc335XpvINIotHHM9r2ImGUSFKFEfrz6MuwQxhpeO6lf8Rr+7a8usLGvkd0rW2VLNdHNKc5s6SpEWiYGkJyJdi0wwUOIyAkD7stfSDv0q+1GPkyIByZF4uF78gouKnc6rSZzwmE1dAYO98hX0R5iwM7T6cyKN3qvNhlslXJJPSfGK6uyANqg4ZH588dlZuDNOoDhDzgOzQrHBkJ30CTGlZGprP8JQo5FByfpPAOmUDjQQjI= 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 Thu 29-08-24 10:33:22, Charlie Jenkins wrote: > 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. Yes, I guess I do understand where you are heading. Our existing model assumes that anybody requiring more address space know what they are doing and deal with the reality. This is the way Linus has pushed this and I am not really convinced it is the right way TBH. On the other hand it is true that this allows a safe(r) transition to larger address spaces. > 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. Right, but this is not really different from earlier attempts to achieve this IIRC. Extentind mmap for that purpose seems quite tricky as already pointed out in other sub-threads. Quite honestly I am not really sure what is the right and backwards compatible way. I just wanted to make you aware this has been discussed at lenght in the past. -- Michal Hocko SUSE Labs