linux-kernel - Re: [PATCH 07/11] mm: shmem: use pgtable_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] [day] [month] [year] [list]

Message-ID: <4c43344e-8ecd-43ba-b8d2-e62e9e0fecb6@redhat.com>
Date: Wed, 17 Dec 2025 13:50:09 -0500
From: Luiz Capitulino <luizcap@...hat.com>
To: Baolin Wang <baolin.wang@...ux.alibaba.com>,
 linux-kernel@...r.kernel.org, linux-mm@...ck.org, david@...nel.org
Cc: ryan.roberts@....com, akpm@...ux-foundation.org,
 lorenzo.stoakes@...cle.com
Subject: Re: [PATCH 07/11] mm: shmem: use pgtable_has_pmd_leaves()

On 2025-12-16 21:03, Baolin Wang wrote:
> 
> 
> On 2025/12/16 21:47, Luiz Capitulino wrote:
>> On 2025-12-16 02:52, Baolin Wang wrote:
>>>
>>>
>>> On 2025/12/16 05:16, Luiz Capitulino wrote:
>>>> Shmem uses has_transparent_hugepage() to check if PMD-sized pages are
>>>> supported, use pgtable_has_pmd_leaves() instead.
>>>>
>>>> Signed-off-by: Luiz Capitulino <luizcap@...hat.com>
>>>> ---
>>>>   mm/shmem.c | 7 ++++---
>>>>   1 file changed, 4 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/mm/shmem.c b/mm/shmem.c
>>>> index b329b5302c48..ad5825667b49 100644
>>>> --- a/mm/shmem.c
>>>> +++ b/mm/shmem.c
>>>> @@ -689,7 +689,8 @@ static int shmem_parse_huge(const char *str)
>>>>       else
>>>>           return -EINVAL;
>>>> -    if (!has_transparent_hugepage() &&
>>>> +    if (!(IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE) &&
>>>> +          pgtable_has_pmd_leaves()) &&
>>>>           huge != SHMEM_HUGE_NEVER && huge != SHMEM_HUGE_DENY)
>>>>           return -EINVAL;
>>>> @@ -4655,7 +4656,7 @@ static int shmem_parse_one(struct fs_context *fc, struct fs_parameter *param)
>>>>           ctx->huge = result.uint_32;
>>>>           if (ctx->huge != SHMEM_HUGE_NEVER &&
>>>>               !(IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE) &&
>>>> -              has_transparent_hugepage()))
>>>> +              pgtable_has_pmd_leaves()))
>>>>               goto unsupported_parameter;
>>>>           ctx->seen |= SHMEM_SEEN_HUGE;
>>>>           break;
>>>> @@ -5439,7 +5440,7 @@ void __init shmem_init(void)
>>>>   #endif
>>>>   #ifdef CONFIG_TRANSPARENT_HUGEPAGE
>>>> -    if (has_transparent_hugepage() && shmem_huge > SHMEM_HUGE_DENY)
>>>> +    if (pgtable_has_pmd_leaves() && shmem_huge > SHMEM_HUGE_DENY)
>>>
>>> Using pgtable_has_pmd_leaves() here is a bit confusing because the definition of pgtable_has_pmd_leaves() is: it returns true if the CPU supports PMD-sized pages and false otherwise.
>>>
>>> However, tmpfs and shmem already support other sizes of large folios, not just PMD-sized large folios.
>>>
>>> So, for me, using has_transparent_hugepage() to check would be at least clearer (even though it doesn't change the functionality).
>>
>> This is more of a naming issue, correct?
> 
> Yes.
> 
>> Would adding something like thp_has_pmd_support() which expands to:
>>
>>      return IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE) && pgtable_has_pmd_leaves();
>>
>> solve it for you? I suggested it in my RFC, but David advised not to do it.
> 
> I agree with David. The thp_has_pmd_support() is not helpful too. What I mean is that the term 'pmd' shouldn't be used here. PMD-sized large folios aren't any more special than others.
> 
> shmem also supports mTHP, and a better approach might be what you did in patch 10: even if PMD-sized pages are not supported on an architecture, shmem can still use other sizes of mTHP.

Oh, I get watch you mean now. I'll have to dig a little deeper into the
shmem code but I'll give your suggestion a try. Thanks for your
feedback.

> 
>> Also, I'm not sure if the comparison with other folio sizes apply, as
>> PUD and PMD sizes are special.
>