linux-kernel - Re: [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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <02f48a21-2dc6-457d-b8a5-bafb9dbb64c2@linux.ibm.com>
Date: Thu, 23 Jan 2025 15:10:37 +0530
From: Hari Bathini <hbathini@...ux.ibm.com>
To: Sourabh Jain <sourabhjain@...ux.ibm.com>,
        Gerald Schaefer <gerald.schaefer@...ux.ibm.com>
Cc: akpm@...ux-foundation.org, 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,
        linux-s390@...r.kernel.org
Subject: Re: [PATCH] mm/hugetlb: bring gigantic page allocation under
 hugepages_supported()



On 23/01/25 9:00 am, Sourabh Jain wrote:
> Hello Gerald,
> 
> On 22/01/25 19:36, Gerald Schaefer wrote:
>> On Tue, 21 Jan 2025 20:34:19 +0530
>> Sourabh Jain <sourabhjain@...ux.ibm.com> wrote:
>>
>>> 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().
>> For s390, hugepages_supported() checks EDAT1 machine flag, which is
>> initialized long before any initcalls. So it is safe to be called
>> here.
> Thanks for the info.
>>
>> My common code hugetlb skills got a little rusty, but shouldn't
>> arch_hugetlb_valid_size() already prevent getting here for gigantic
>> hugepages, in case they are not supported? And could you not use
>> that for your purpose?
> 
> Yes, handling this in arch_hugetlb_valid_size is even better. That way,
> we can avoid initializing data structures to hold hstate, which is not
> required anyway.
> 
> Thanks for the review and suggestion. I will handle this in the
> architecture-specific code.

Yeah, adding a check for hugetlb_disabled in arch_hugetlb_valid_size()
should take care of things?

- Hari