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 7E215C71143 for ; Wed, 28 Aug 2024 20:59:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 122556B0085; Wed, 28 Aug 2024 16:59:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0AAF56B0088; Wed, 28 Aug 2024 16:59:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E3FD66B0089; Wed, 28 Aug 2024 16:59:28 -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 C0D5A6B0085 for ; Wed, 28 Aug 2024 16:59:28 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 66E72C07B6 for ; Wed, 28 Aug 2024 20:59:28 +0000 (UTC) X-FDA: 82502870016.24.363664E Received: from mail-pf1-f169.google.com (mail-pf1-f169.google.com [209.85.210.169]) by imf02.hostedemail.com (Postfix) with ESMTP id 8321680006 for ; Wed, 28 Aug 2024 20:59:24 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=rivosinc-com.20230601.gappssmtp.com header.s=20230601 header.b=bct3bPud; spf=pass (imf02.hostedemail.com: domain of charlie@rivosinc.com designates 209.85.210.169 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=1724878695; 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=i/zDBXzpitxR3zo9kDta1Br+UZ/dQrtli222s8BWZ0g=; b=JiYOvLaMLB6N91TMrosvgxLMIqXTQbvvPa8+gPGiE9WGFJc90PwNPziB3/oaYa+zUoZRhr 6FFqwZP7KVMzb9McQqya6sP79gaHTj7tX24H6CLm01fNmNvnQla/LzyWq/ftsPi1A5G5xL 5boDbD7m7q3lH91/pT9Q8SjsvpkSXoc= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=rivosinc-com.20230601.gappssmtp.com header.s=20230601 header.b=bct3bPud; spf=pass (imf02.hostedemail.com: domain of charlie@rivosinc.com designates 209.85.210.169 as permitted sender) smtp.mailfrom=charlie@rivosinc.com; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724878695; a=rsa-sha256; cv=none; b=VuqWw1mjZnIhDjYAhohKKYQttyNokTYcSu0FmEwATbVg57A3N4NSuJSrw8DsNaGP9P7OFO N2kxIOFy3ZdGJLFDk4ilroiKZuuXr9tkbH+0lka7hdJ9mGI9dss53l3fdg6vpNJV05OSgn YLI30d54MNX8KlkyLadJZLwXn2rLkR0= Received: by mail-pf1-f169.google.com with SMTP id d2e1a72fcca58-7143165f23fso5297549b3a.1 for ; Wed, 28 Aug 2024 13:59:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20230601.gappssmtp.com; s=20230601; t=1724878763; x=1725483563; 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=i/zDBXzpitxR3zo9kDta1Br+UZ/dQrtli222s8BWZ0g=; b=bct3bPud0gzwxhkYBZyCE0dr/adA0HkEiDhxK178WDRc3Av3DpnmTbrek0vvcTU8pe VK1oIAMc1NZIIJovvq1Y74Xhgl8sf9Fw+4hWqIzgHPPmMxNTeMKaZPTsvZ3axc3cUZjq 4nDNJkwzJdSTccti6bd7yEnNpZoij4Gy+7qonJUlb63Mhw1gOONRG1ZeYGCorFax41Ff gi+NW9MH0+0xHstpVKS8zmMRjM8lTjEsFt/MhJvEfXD3Us4Ukv4mvjL+xojFaGVXN+ny RamWT0XQd+ttqwZy9qgGcs0wYbU0/2kWsp2Wqvs9DbuIvn4UbFRRukSuywiPexjxrE5S HUBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724878763; x=1725483563; 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=i/zDBXzpitxR3zo9kDta1Br+UZ/dQrtli222s8BWZ0g=; b=aoJEE8OBpL5ErOvLeoZIE7ii8RoH4CjGzQcttOYdos2rvCW0IzHWsa6dQIT+YHb4gr yM3//MfefyWPYSVHnP13OkwZvCYf7PGESIXgSB6sp2cXGjYAx9U8/p21G09s7zZFSpjN 76KHL6XXOEUM3rfygteQ2igAm0WfmemM0Z2Y+a743zclLaucDAOEzispfHAzeM19gSdG Kfhp1FlAOt8d17qfqc4i2tvX9bG81qtMpRwQ3Ur+eSOQe8WGfrFZs05jwqK9F29Z/TRN vY+5+UI/kqT1KOhyt8Ni5omnPfW+6a68h6d7norbED4AAx5jyca3rmg8/5gj/aCGEF7c JTdw== X-Forwarded-Encrypted: i=1; AJvYcCX0KaPlAVStFAm3fsknCiiAzXRaSsr9ijxvnsWHIqk7BbazA9OJMHHZpVc3HF6vuvhepCQGudrX0w==@kvack.org X-Gm-Message-State: AOJu0YwFSF5UZf/PLwFM7rsZbadfTTE5Y9Ix/idqXtDO35CTHCC8Kslw rsJjWQq/rckJzXsy1HUPbRUQs8LwKBCCr1wOvP8vTzUO1DxcvpShpwYHWEFTQB8= X-Google-Smtp-Source: AGHT+IG7I/ksvpo1L5d4I2EaTAuTvr9NK9oL0S5iJqb7m4xLEH9N4JCU4pfHpqjb0Cf1ei4I8vFF1g== X-Received: by 2002:a05:6a00:2191:b0:70b:1b51:b8af with SMTP id d2e1a72fcca58-715dfc92f6fmr921313b3a.19.1724878762830; Wed, 28 Aug 2024 13:59:22 -0700 (PDT) Received: from ghost ([50.145.13.30]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-714468bf2dbsm8722718b3a.102.2024.08.28.13.59.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 28 Aug 2024 13:59:22 -0700 (PDT) Date: Wed, 28 Aug 2024 13:59:18 -0700 From: Charlie Jenkins To: "Liam R. Howlett" Cc: Arnd Bergmann , Paul Walmsley , Palmer Dabbelt , Albert Ou , Catalin Marinas , Will Deacon , Michael Ellerman , Nicholas Piggin , Christophe Leroy , Naveen N Rao , Muchun Song , Andrew Morton , Vlastimil Babka , Lorenzo Stoakes , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Huacai Chen , WANG Xuerui , Russell King , Thomas Bogendoerfer , "James E.J. Bottomley" , Helge Deller , 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 , Shuah Khan , Alexandre Ghiti , linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org, Palmer Dabbelt , linux-riscv@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, linux-mm@kvack.org, loongarch@lists.linux.dev, linux-mips@vger.kernel.org, linux-parisc@vger.kernel.org, linux-s390@vger.kernel.org, linux-sh@vger.kernel.org, sparclinux@vger.kernel.org, linux-kselftest@vger.kernel.org Subject: Re: [PATCH 00/16] mm: Introduce MAP_BELOW_HINT Message-ID: References: <20240827-patches-below_hint_mmap-v1-0-46ff2eb9022d@rivosinc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Stat-Signature: w75sp5k7k4fynys7zzyzjiirc196n366 X-Rspam-User: X-Rspamd-Queue-Id: 8321680006 X-Rspamd-Server: rspam02 X-HE-Tag: 1724878764-923650 X-HE-Meta: U2FsdGVkX18MME70TCrPoJA2ingfuiQ9CsK2g33YRbj3VbqS7A1RHCAkvHRE3qtTez2Pum7qhhinrPivjusn0Sdg+/CQV92AyXXh1rreMrJyvsNHvAiStNTxFntj3ufiNBl8Patc52aMdqMvLGj/aQ4Uco8m3eiWIgwaSdLYhtZ+A+OFZmGZxIAYOJK2SOxeBkyEeFe7wSYifP/j7ittd0t6Sp+5/kK/8CdwyvMk9LO837WMk6+ZU3MGp/YaAYcSmDwVi/nWajACPVScsB6zos6V1czG+G5i0Y3LlVtTvRVegtdxnxegMFmxI8AZ21tPM/ULZjnyCNnlb/Y+WzQzMLv1QPedVLkou8pHmNthqZ0frZjebr/cjFp6vlg3pos93iovCCkCNJvKFZsrl78uRCzWUupdxsWhfQZnVEAWwH5zuvKZTpmE+rNHAiN2SE+aEaEl46+LI5sxO6+OLmlKRx4/8khaW6oN3GjLb0q69BkrK4b/f/mLRL8tJJGT60p7v1qHhzNAr+DfuD5LgtrcUImhbDeXBLQaa3jEso0anr11AhRS4LPCU+WMsEPq/LZPVJkinncLX3HwIoZSwbSp1KUpFUGiommQJtDunB18iM47TBIKr7j4V2fVNPqKXSKIuEYN5Qh4DxNeoMIpH/9yoDjgZsBQsf1qEFbMsIjW6jiYIlhlWoUOnj2z8WrIuc0zkwvR9/2AwdexbLfICsV5JXcASseGNM9jCGUpUjjpdyO3pEfbDex3TBkAAzKDI7fC65UKX8xtX/lRsAo0bWlU7RIHvUya76mUhoWjBfq6XgHCUi9OtIdKsQdJyYW2aX0sQqSQ45wCx9Gc/GhxlMyqeMgSgPZWJm88qrkiMI4TQl+TdGr0c+3TetxSfyUM8i5mwqc47W5Z2yhZFVFyvtRUedRwZp9Hr+agrK7EB0mP3tMnPhs0sc9ZUsPJ09MkuXWE2HYq+VZgqgngjonlM88 lMWfB5Zo OdP8/xxzl8Ji0XD2JNFXPwBCfs64XF6tbhIuwyGtf+ap3uvCJLjQRX2+vTUmepg5KfXBY8QNX9hvACH0j1ECNVNscEQSG+0r7DKIHhy9q6m3bqQUvld5xYrOLgzVdFaee5ypT9Xt7WCUR+A91Na2vS5wS44yGoOJMAOgUOw9A/BYIBaWoybb6nF6O59Z0wkk3YdDDSTMRq3avcwQdxW3WLhOWK7Am1WsbQD8nr2TVVEJQs2F/gPogahKqVWY/2P0kWyTNUs1A9O7RwS0BXcOI54BDlzvcjTgKQBDHxPyAN4ZzU4/EYuvR8s6ItcQkBk6R58EOIrv+rqoOj4qGL4MODOgDPeHTlk62AJLZTxjLQEFmdYBlJxNRfkRmYDNCRgbe4g9L1wBeGIr77+y9Eym8Gsiclwj6TQinqMQkcvnIPpldWFrtAIodbJQno0ZTVppoWi3ivSP+TBYICta5kV1fsi/jN9KqCPuh1La8ZAKMYC2gG1NfnG3B3gSBBqGshP6XeDvFIJgWIz64ESPGr5TIEC87EaakleRXmQizFu+f7h9kKHlYPJj1Z3s6F+w9n5Q62cskzO3HcxqkhzLg2A8YrWSUn8NQPSMoFkwjA6Ix0S5uGV4U8wKoTJ84isorHRJHl70qOIV1wr+HNGP5ZoBCjmRlE9EAnGRGDEWnjIwWBhmxGSlpca36IT/tV6CUBwG3K7UiRQIqZd8npZaig+C3LAdSNjOdbMoTA6TbwfpxoyUcOkktfnQxaySOsAOS6F7NcriVZ+SuUreZ41EhWPDDHbpY15VCvCkcl5aVJMTG7qPW7JWZ5P/Eq7C9XVTJWnhwUPiCy7CzFdxNNbWne/CSyOI43phA2aE7gHl1qrusme4/XBeX3urwnAbwWJTaBKtWuokldmn2MVhPBLLJmfQ/89iLTkh9qT/cWqTjdE++ctZbP6guOIwkQr62NTfvd3LiS1Rvxkw8oqJzIJT1m2961uYrX/IF 8/6EA1Xg s/ipP0Vq4m73qAXi8h2KKUnYmzPqbFBF0ketxN7jh3A4eq49UIu0ld8Pnn0Tl8dnSmL5r+Tm3+uuvNu4Ucn+Aj9YfH6rMXiGpqVi+5EUgHgvweP5qM/XbJGQMHmp1QCyue6oAJnUPGRoGbY6vpJSb/8EOsa9frQydD8WP2NKNuVqKyiwugfr5F4G7NqQHAGlhYc0/pqJu1UbqNldb3BrzRauEcW2xzbzKMoi9nkfCZK1jIrlkESQirvKl7qYQLFrw0vsvrKVTXiCZXOw1o9oebr+0LbTAaF4f4zIo+3ewZI/9PAFFNPbZmwhVdTs0NsFTGzaiGvqJTjZj6/m9iAUPpvgAk735PpOULKfk+CR4yOdd2hfycqUDp0QsNxplReim/tQIV8ryU3B3Fa0fUYMAODURQLxvkHUoD6rJeN5Vd7J5jLqqPGzAZ08SEjr7FUC+e9MJ0o7i2gp9sZEuQ1zC8euic7GQeHDF0vgwKN+r9xbISMYVdw95A== 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 Wed, Aug 28, 2024 at 02:31:42PM -0400, Liam R. Howlett wrote: > * Charlie Jenkins [240828 01:49]: > > 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 maximum address space, > > unless the hint address is greater than this value. > > Wait, what arch(s) allows for greater than the max? The passed hint > should be where we start searching, but we go to the lower limit then > start at the hint and search up (or vice-versa on the directions). > I worded this awkwardly. On arm64 there is a page-table boundary at 48 bits and at 52 bits. On x86 the boundaries are at 48 bits and 57 bits. The max value mmap is able to return on arm64 is 48 bits if the hint address uses 48 bits or less, even if the architecture supports 5-level paging and thus addresses can be 52 bits. Applications can opt-in to using up to 52-bits in an address by using a hint address greater than 48 bits. x86 has the same behavior but with 57 bits instead of 52. This reason this exists is because some applications arbitrarily replace bits in virtual addresses with data with an assumption that the address will not be using any of the bits above bit 48 in the virtual address. As hardware with larger address spaces was released, x86 decided to build safety guards into the kernel to allow the applications that made these assumptions to continue to work on this different hardware. This causes all application that use a hint address to silently be restricted to 48-bit addresses. The goal of this flag is to have a way for applications to explicitly request how many bits they want mmap to use. > I don't understand how unmapping works on a higher address; we would > fail to free it on termination of the application. > > Also, there are archs that map outside of the VMAs, which are freed by > freeing from the prev->vm_end to next->vm_start, so I don't understand > what that looks like in this reality as well. > > > > > On arm64 this barrier is at 52 bits and on x86 it is at 56 bits. This > > flag allows applications a way to specify exactly how many bits they > > want to be left unused by mmap. This eliminates the need for > > applications to know the page table hierarchy of the system to be able > > to reason which addresses mmap will be allowed to return. > > But, why do they need to know today? We have a limit for this don't we? The limit is different for different architectures. On x86 the limit is 57 bits, and on arm64 it is 52 bits. So in the theoretical case that an application requires 10 bits free in a virtual address, the application would always work on arm64 regardless of the hint address, but on x86 if the hint address is greater than 48 bits then the application will not work. The goal of this flag is to have consistent and tunable behavior of mmap() when it is desired to ensure that mmap() only returns addresses that use some number of bits. > > Also, these upper limits are how some archs use the upper bits that you > are trying to use. > It does not eliminate the existing behavior of the architectures to place this upper limits, it instead provides a way to have consistent behavior across all architectures. > > > > --- > > riscv made this feature of mmap returning addresses less than the hint > > address the default behavior. This was in contrast to the implementation > > of x86/arm64 that have a single boundary at the 5-level page table > > region. However this restriction proved too great -- the reduced > > address space when using a hint address was too small. > > Yes, the hint is used to group things close together so it would > literally be random chance on if you have enough room or not (aslr and > all). > > > > > A patch for riscv [1] reverts the behavior that broke userspace. This > > series serves to make this feature available to all architectures. > > I don't fully understand this statement, you say it broke userspace so > now you are porting it to everyone? This reads as if you are braking > the userspace on all architectures :) It was the default for mmap on riscv. The difference here is that it is now enabled by a flag instead. Instead of making the flag specific to riscv, I figured that other architectures might find it useful as well. > > If you fail to find room below, then your application fails as there is > no way to get the upper bits you need. It would be better to fix this > in userspace - if your application is returned too high an address, then > free it and exit because it's going to fail anyways. > This flag is trying to define an API that is more robust than the current behavior on that x86 and arm64 which implicitly restricts mmap() addresses to 48 bits. A solution could be to just write in the docs that mmap() will always exhaust all addresses below the hint address before returning an address that is above the hint address. However a flag that defines this behavior seems more intuitive. > > > > I have only tested on riscv and x86. > > This should be an RFC then. Fair enough. > > > There is a tremendous amount of > > duplicated code in mmap so the implementations across architectures I > > believe should be mostly consistent. I added this feature to all > > architectures that implement either > > arch_get_mmap_end()/arch_get_mmap_base() or > > arch_get_unmapped_area_topdown()/arch_get_unmapped_area(). I also added > > it to the default behavior for arch_get_mmap_end()/arch_get_mmap_base(). > > Way too much duplicate code. We should be figuring out how to make this > all work with the same code. > > This is going to make the cloned code problem worse. That would require standardizing every architecture with the generic mmap() framework that arm64 has developed. That is far outside the scope of this patch, but would be a great area to research for each of the architectures that do not use the generic framework. - Charlie > > > > > Link: https://lore.kernel.org/lkml/20240826-riscv_mmap-v1-2-cd8962afe47f@rivosinc.com/T/ [1] > > > > To: Arnd Bergmann > > To: Paul Walmsley > > To: Palmer Dabbelt > > To: Albert Ou > > To: Catalin Marinas > > To: Will Deacon > > To: Michael Ellerman > > To: Nicholas Piggin > > To: Christophe Leroy > > To: Naveen N Rao > > To: Muchun Song > > To: Andrew Morton > > To: Liam R. Howlett > > To: Vlastimil Babka > > To: Lorenzo Stoakes > > To: Thomas Gleixner > > To: Ingo Molnar > > To: Borislav Petkov > > To: Dave Hansen > > To: x86@kernel.org > > To: H. Peter Anvin > > To: Huacai Chen > > To: WANG Xuerui > > To: Russell King > > To: Thomas Bogendoerfer > > To: James E.J. Bottomley > > To: Helge Deller > > To: Alexander Gordeev > > To: Gerald Schaefer > > To: Heiko Carstens > > To: Vasily Gorbik > > To: Christian Borntraeger > > To: Sven Schnelle > > To: Yoshinori Sato > > To: Rich Felker > > To: John Paul Adrian Glaubitz > > To: David S. Miller > > To: Andreas Larsson > > To: Shuah Khan > > To: Alexandre Ghiti > > Cc: linux-arch@vger.kernel.org > > Cc: linux-kernel@vger.kernel.org > > Cc: Palmer Dabbelt > > Cc: linux-riscv@lists.infradead.org > > Cc: linux-arm-kernel@lists.infradead.org > > Cc: linuxppc-dev@lists.ozlabs.org > > Cc: linux-mm@kvack.org > > Cc: loongarch@lists.linux.dev > > Cc: linux-mips@vger.kernel.org > > Cc: linux-parisc@vger.kernel.org > > Cc: linux-s390@vger.kernel.org > > Cc: linux-sh@vger.kernel.org > > Cc: sparclinux@vger.kernel.org > > Cc: linux-kselftest@vger.kernel.org > > Signed-off-by: Charlie Jenkins > > > > --- > > Charlie Jenkins (16): > > mm: Add MAP_BELOW_HINT > > riscv: mm: Do not restrict mmap address based on hint > > mm: Add flag and len param to arch_get_mmap_base() > > mm: Add generic MAP_BELOW_HINT > > riscv: mm: Support MAP_BELOW_HINT > > arm64: mm: Support MAP_BELOW_HINT > > powerpc: mm: Support MAP_BELOW_HINT > > x86: mm: Support MAP_BELOW_HINT > > loongarch: mm: Support MAP_BELOW_HINT > > arm: mm: Support MAP_BELOW_HINT > > mips: mm: Support MAP_BELOW_HINT > > parisc: mm: Support MAP_BELOW_HINT > > s390: mm: Support MAP_BELOW_HINT > > sh: mm: Support MAP_BELOW_HINT > > sparc: mm: Support MAP_BELOW_HINT > > selftests/mm: Create MAP_BELOW_HINT test > > > > arch/arm/mm/mmap.c | 10 ++++++++ > > arch/arm64/include/asm/processor.h | 34 ++++++++++++++++++++++---- > > arch/loongarch/mm/mmap.c | 11 +++++++++ > > arch/mips/mm/mmap.c | 9 +++++++ > > arch/parisc/include/uapi/asm/mman.h | 1 + > > arch/parisc/kernel/sys_parisc.c | 9 +++++++ > > arch/powerpc/include/asm/task_size_64.h | 36 +++++++++++++++++++++++----- > > arch/riscv/include/asm/processor.h | 32 ------------------------- > > arch/s390/mm/mmap.c | 10 ++++++++ > > arch/sh/mm/mmap.c | 10 ++++++++ > > arch/sparc/kernel/sys_sparc_64.c | 8 +++++++ > > arch/x86/kernel/sys_x86_64.c | 25 ++++++++++++++++--- > > fs/hugetlbfs/inode.c | 2 +- > > include/linux/sched/mm.h | 34 ++++++++++++++++++++++++-- > > include/uapi/asm-generic/mman-common.h | 1 + > > mm/mmap.c | 2 +- > > tools/arch/parisc/include/uapi/asm/mman.h | 1 + > > tools/include/uapi/asm-generic/mman-common.h | 1 + > > tools/testing/selftests/mm/Makefile | 1 + > > tools/testing/selftests/mm/map_below_hint.c | 29 ++++++++++++++++++++++ > > 20 files changed, 216 insertions(+), 50 deletions(-) > > --- > > base-commit: 5be63fc19fcaa4c236b307420483578a56986a37 > > change-id: 20240827-patches-below_hint_mmap-b13d79ae1c55 > > -- > > - Charlie > >