Re: [PATCH v2] x86/mm: Drop the page allocation from pud_free_pmd_page()

[Dave Hansen <dave.hansen@intel.com>]

On 9/23/26 22:10, Mikhail Gavrilov wrote:
> On 9/23/26 16:07, Dave Hansen wrote:
>> There are a few things we need to figure out like having
>> pmd_free_pte_page() return 'int' when it doesn't ever fail, the
>> comments, and the reverse Christmas tree.
> 
> One data point for the return value: the x86-PAE pmd_free_pte_page()
> does fail.  It returns pmd_none(*pmd), and vmap_try_huge_pmd() relies
> on that to keep ioremap() from replacing an existing PTE table there
> (the comment above it is about the sync'd PMD entries).  Huge PMD vmap
> is enabled on PAE whenever the CPU has PSE.

Oh, that's just kinda silly. We should just zap that version and huge
PMD vmap on 32-bit.

> pud_free_pmd_page() has no such case: the PUD level is 64-bit only on
> x86, and with v2 applied the x86-64 version, like the arm64, riscv and
> powerpc ones, always returns 1.

Yeah, all the ones for CPUs from this millennium are OK.

>> I'll dig into it a bit tomorrow and see what I come up with.
> 
> Thanks.  This box reaches pud_free_pmd_page() on every boot I have
> checked, so I can run whatever you come up with through the same
> boot-time kprobe and reproducer check.

I think I'll just take your version since you actually, you know,
compiled it and all. ;)