Re: [PATCH 1/1] mm/huge_memory: fix pgtable withdrawal for huge zero PMDs

[Lance Yang <lance.yang@linux.dev>]

On Sat, Sep 12, 2026 at 11:46:35PM -0700, Andrew Morton wrote:
>On Sun, 13 Sep 2026 13:19:42 +0800 Lance Yang <lance.yang@linux.dev> wrote:
>
>> From: Lance Yang <lance.yang@linux.dev>
>> 
>> has_deposited_pgtable() uses !vma_is_dax() to decide whether a huge zero
>> PMD has a deposited PTE page table. That also accepts raw PFN mappings
>> of huge_zero_pfn, although vmf_insert_pfn_pmd() does not deposit a page
>> table on x86.
>> 
>> Zapping such a mapping would call pgtable_trans_huge_withdraw() without
>> a corresponding deposit. With pmd_huge_pte(mm, pmd) == NULL, that causes
>> a NULL pointer dereference.
>
>That's the sort of thing we'd prefer to avoid.
>
>> Use vma_is_anonymous() for the huge zero PMD check. This matches how PTE
>> page tables are allocated, deposited and moved.
>> 
>> - For anonymous page faults that install a huge zero PMD,
>>   do_huge_pmd_anonymous_page() allocates a PTE page table and
>>   set_huge_zero_folio() deposits it before installing the PMD.
>> 
>> - On fork, copy_huge_pmd() allocates and deposits a PTE page table when
>>   copying a huge zero PMD into an anonymous VMA.
>> 
>> - Raw PFN mappings use vmf_insert_pfn_pmd(), and DAX file holes use
>>   vmf_insert_folio_pmd() to map the huge zero folio. Both use insert_pmd(),
>>   which deposits a PTE page table only when arch_needs_pgtable_deposit()
>>   requires it.
>> 
>> - Moving an anonymous huge PMD preserves its deposited PTE page table.
>>   move_huge_pmd() transfers the deposit when necessary. For UFFD MOVE,
>>   both VMAs must be anonymous, and move_pages_huge_pmd() transfers the
>>   deposit as well.
>> 
>> Keep arch_needs_pgtable_deposit() first so architectures that require a
>> deposited PTE page table still return true regardless of the VMA type.
>> 
>> Commit d80a9cb1a64a ("mm/huge_memory: add and use
>> normal_or_softleaf_folio_pmd()") removed the vma_is_special_huge() check
>> in zap_huge_pmd(). That check skipped the huge zero PMD deposit test for
>> non-DAX VM_PFNMAP and VM_MIXEDMAP mappings. Removing it exposed these
>> mappings to the incorrect !vma_is_dax() test.
>> 
>> Fixes: d80a9cb1a64a ("mm/huge_memory: add and use normal_or_softleaf_folio_pmd()")
>> Cc: stable@vger.kernel.org
>
>How real is this?  Is there a reported-by:?  Do you have a reproducer? 

Yes, I reproduced it on x86 with a small test module. It sets
VM_MIXEDMAP | VM_HUGEPAGE and calls vmf_insert_pfn_pmd() with
huge_zero_pfn, without touching the page tables directly. A full-PMD
munmap() crashes before the split series[1] as well.

>Is it a theoretical, LLM-found-this thing which can't really happen?

I found this while reviewing the split series with LLM assistance.

mshv_vtl_low derives the PFN from the mmap offset, and its checks do not
exclude huge_zero_pfn. I haven't tested this on a Hyper-V, though.

[1] https://lore.kernel.org/linux-mm/cover.1787941780.git.yintirui@gmail.com/

>> --- a/mm/huge_memory.c
>> +++ b/mm/huge_memory.c
>> @@ -2529,11 +2529,11 @@ static bool has_deposited_pgtable(struct vm_area_struct *vma, pmd_t pmdval,
>>  		return true;
>>  
>>  	/*
>> -	 * Huge zero always deposited except for DAX which handles itself, see
>> -	 * set_huge_zero_folio().
>> +	 * Huge zero PMDs have a deposited page table only for anonymous VMAs,
>> +	 * see set_huge_zero_folio().
>>  	 */
>>  	if (is_huge_zero_pmd(pmdval))
>> -		return !vma_is_dax(vma);
>> +		return vma_is_anonymous(vma);
>>  
>>  	/*
>>  	 * Otherwise, only anonymous folios are deposited, see
>
>Thanks, I'll add it for test-n-review.

Thanks!