linux-kernel - Re: [RFC 07/10] treewide: rename has_transparent_hugepage() to arch_has_pmd

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <3fcce19e-ed78-4b83-bbdd-e925a74091b2@kernel.org>
Date: Tue, 2 Dec 2025 11:53:01 +0100
From: "David Hildenbrand (Red Hat)" <david@...nel.org>
To: Luiz Capitulino <luizcap@...hat.com>, linux-kernel@...r.kernel.org,
 linux-mm@...ck.org
Cc: ryan.roberts@....com, akpm@...ux-foundation.org,
 lorenzo.stoakes@...cle.com
Subject: Re: [RFC 07/10] treewide: rename has_transparent_hugepage() to
 arch_has_pmd_leaves()

On 11/17/25 20:01, Luiz Capitulino wrote:
> On 2025-11-17 12:45, David Hildenbrand (Red Hat) wrote:
>> On 06.11.25 22:28, Luiz Capitulino wrote:
>>> Now that the majority of has_transparent_hugepage() callers have been
>>> converted to pgtable_has_pmd_leaves(), rename has_transparent_hugepage()
>>> to arch_has_pmd_leaves() since that's what the helper checks for.
>>>
>>> arch_has_pmd_leaves() is supposed to be called only by
>>> init_arch_has_pmd_leaves(), except for two exeptions:
>>>
>>> 1. shmem: shmem code runs very early during boot so it can't use
>>>      pgtable_has_pmd_leaves()
>>
>> Can't we just initialize pgtable_has_pmd_leaves() earlier then?
> 
> I can look into doing that. When I worked on this RFC I wondered if
> arch_has_pmd_leaves() (when implemented by the arch) could run so early
> given that some (all?) archs check feature bits so they must be
> available this early as well. But I'll check this, having
> pgtable_has_pmd_leaves() being available as early as possible is
> probably the right thing to do.
> 
>>> 2. hugepage_init(): just a temporary exception, this function will be
>>>      converted in a future commit
>>>
>>> Signed-off-by: Luiz Capitulino <luizcap@...hat.com>
>>> ---
>>
>>
>> [...]
>>
>>> diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
>>> index e4c5f70b0a01..02a2772ec548 100644
>>> --- a/include/linux/pgtable.h
>>> +++ b/include/linux/pgtable.h
>>> @@ -2026,8 +2026,8 @@ static inline bool pgtable_has_pmd_leaves(void)
>>>    #endif
>>>    #endif
>>> -#ifndef has_transparent_hugepage
>>> -#define has_transparent_hugepage() IS_BUILTIN(CONFIG_TRANSPARENT_HUGEPAGE)
>>> +#ifndef arch_has_pmd_leaves
>>> +#define arch_has_pmd_leaves() IS_BUILTIN(CONFIG_TRANSPARENT_HUGEPAGE)
>>>    #endif
>>
>> Ah, so it stays for now only set with CONFIG_TRANSPARENT_HUGEPAGE. I guess that's something to sort out later :)
> 
> I suggested something we could do in this series. Also, I skipped
> commenting on all the cases you spotted as I think they refer to the
> same issue (please, do point out if you think I'm wrong).

Right. If we keep PMD-leave support glue to CONFIG_TRANSPARENT_HUGEPAGE 
in this series, could we also simplify patch #2, to have it reside in 
mm/huge_memory.c ?

Then, it's clearer that it is still glued to CONFIG_TRANSPARENT_HUGEPAGE.

-- 
Cheers

David