linux-kernel - [PATCH] mm/hugetlb: bring gigantic page allocation under hugepages

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250121150419.1342794-1-sourabhjain@linux.ibm.com>
Date: Tue, 21 Jan 2025 20:34:19 +0530
From: Sourabh Jain <sourabhjain@...ux.ibm.com>
To: akpm@...ux-foundation.org
Cc: Sourabh Jain <sourabhjain@...ux.ibm.com>,
        Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
        Borislav Petkov <bp@...en8.de>, Heiko Carstens <hca@...ux.ibm.com>,
        Vasily Gorbik <gor@...ux.ibm.com>, Muchun Song <muchun.song@...ux.dev>,
        Madhavan Srinivasan <maddy@...ux.ibm.com>,
        Michael Ellerman <mpe@...erman.id.au>, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org
Subject: [PATCH] mm/hugetlb: bring gigantic page allocation under hugepages_supported()

Despite having kernel arguments to enable gigantic hugepages, this
provides a way for the architecture to disable gigantic hugepages on the
fly, similar to what we do for hugepages.

Components like fadump (PowerPC-specific) need this functionality to
disable gigantic hugepages when the kernel is booted solely to collect
the kernel core dump.

Cc: Thomas Gleixner <tglx@...utronix.de>
Cc: Ingo Molnar <mingo@...hat.com>
Cc: Borislav Petkov <bp@...en8.de>
Cc: Heiko Carstens <hca@...ux.ibm.com>
Cc: Vasily Gorbik <gor@...ux.ibm.com>
Cc: Muchun Song <muchun.song@...ux.dev>
Cc: Madhavan Srinivasan <maddy@...ux.ibm.com>
Cc: Michael Ellerman <mpe@...erman.id.au>
Cc: linux-mm@...ck.org
Cc: linux-kernel@...r.kernel.org
Cc: linuxppc-dev@...ts.ozlabs.org
Signed-off-by: Sourabh Jain <sourabhjain@...ux.ibm.com>
---

To evaluate the impact of this change on architectures other than
PowerPC, I did the following analysis:

For architectures where hugepages_supported() is not redefined, it
depends on HPAGE_SHIFT, which is found to be a constant. It is mostly
initialized to PMD_SHIFT.

Architecture : HPAGE_SHIFT initialized with

ARC: PMD_SHIFT (constant)
ARM: PMD_SHIFT (constant)
ARM64: PMD_SHIFT (constant)
Hexagon: 22 (constant)
LoongArch: (PAGE_SHIFT + PAGE_SHIFT - 3) (appears to be constant)
MIPS: (PAGE_SHIFT + PAGE_SHIFT - 3) (appears to be constant)
PARISC: PMD_SHIFT (appears to be constant)
RISC-V: PMD_SHIFT (constant)
SH: 16 | 18 | 20 | 22 | 26 (constant)
SPARC: 23 (constant)

So seems like this change shouldn't have any impact on above
architectures.

On the S390 and X86 architectures, hugepages_supported() is redefined,
and I am uncertain at what point it is safe to call
hugepages_supported().

---
 mm/hugetlb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index cec4b121193f..48b42b8d26b4 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -4629,7 +4629,7 @@ static int __init hugepages_setup(char *s)
 	 * But we need to allocate gigantic hstates here early to still
 	 * use the bootmem allocator.
 	 */
-	if (hugetlb_max_hstate && hstate_is_gigantic(parsed_hstate))
+	if (hugetlb_max_hstate && hstate_is_gigantic(parsed_hstate) && hugepages_supported())
 		hugetlb_hstate_alloc_pages(parsed_hstate);
 
 	last_mhp = mhp;
-- 
2.47.1