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-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <324b64d3-2d12-462c-9afc-070dd100c582@linux.alibaba.com>
Date: Wed, 17 Dec 2025 10:03:38 +0800
From: Baolin Wang <baolin.wang@...ux.alibaba.com>
To: Luiz Capitulino <luizcap@...hat.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: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.

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


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ