linux-kernel - Re: [PATCH 1/3] sparc64: remove hugetlb_free_pgd

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: <bc3fc8e9-2841-450c-8c61-f3575715939b@oracle.com>
Date: Wed, 16 Jul 2025 09:42:50 -0700
From: Anthony Yznaga <anthony.yznaga@...cle.com>
To: David Hildenbrand <david@...hat.com>, davem@...emloft.net,
        andreas@...sler.com, arnd@...db.de, muchun.song@...ux.dev,
        osalvador@...e.de, akpm@...ux-foundation.org,
        lorenzo.stoakes@...cle.com, Liam.Howlett@...cle.com, vbabka@...e.cz,
        rppt@...nel.org, surenb@...gle.com, mhocko@...e.com
Cc: linux-mm@...ck.org, sparclinux@...r.kernel.org, linux-arch@...r.kernel.org,
        linux-kernel@...r.kernel.org, alexghiti@...osinc.com,
        agordeev@...ux.ibm.com, anshuman.khandual@....com,
        christophe.leroy@...roup.eu, ryan.roberts@....com, will@...nel.org
Subject: Re: [PATCH 1/3] sparc64: remove hugetlb_free_pgd_range()



On 7/16/25 1:20 AM, David Hildenbrand wrote:
> On 16.07.25 03:26, Anthony Yznaga wrote:
>> The sparc implementation of hugetlb_free_pgd_range() is identical
>> to free_pgd_range() with the exception of checking for and skipping
>> possible leaf entries at the PUD and PMD levels.
> 
> And the pgd loop was optimized out, because probably not applicable.
> 
>> These checks are
>> unnecessary because any huge pages have been freed and their PTEs
>> cleared by the time page tables needed to map them are freed.
> 
> Do we know why that handling was added in the first place, and why it no 
> longer applies?

The PMD handling was added by 7bc3777ca19c (sparc64: Trim page tables 
for 8M hugepages). The only clue is that the commit message has the 
sentence, "Also, when freeing page table for 8M hugepage backed region, 
make sure we don't try to access non-existent PTE level." I'd guess that 
it was something left over from development that snuck in. The patch is 
changing from storing 1024 PTEs at the PTE level for an 8M hugetlb page 
to storing a single PMD entry.

> 
> These is_hugetlb_pmd/is_hugetlb_pud are rather weird on the code path.
> 
> Looks like a very nice cleanup.
>