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

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

[Lance Yang]

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.

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
Signed-off-by: Lance Yang <lance.yang@linux.dev>
---
 mm/huge_memory.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 6895b38e4704..0ed997a97416 100644
--- 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
-- 
2.39.3 (Apple Git-146)

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

[Andrew Morton]

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? 
Is it a theoretical, LLM-found-this thing which can't really happen?

> --- 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.

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

[Lance Yang]

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!

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

[Kiryl Shutsemau]

On Sun, Sep 13, 2026 at 03:23:12PM +0800, Lance Yang wrote:
> 
> 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.

Ah. So there's no real bug upstream, right?

And I am not sure it is how we want to address this. I don't think we
should allow randomly map huge zero page (and non-huge too). It can be a
security risk if it ever gets exposed writable.

See CVE-2015-3288 and 6b7339f4c31a ("mm: avoid setting up anonymous
pages into file mapping").

-- 
  Kiryl Shutsemau / Kirill A. Shutemov

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

[David Hildenbrand (Arm)]

On 9/14/26 12:59, Kiryl Shutsemau wrote:
> On Sun, Sep 13, 2026 at 03:23:12PM +0800, Lance Yang wrote:
>>
>> On Sat, Sep 12, 2026 at 11:46:35PM -0700, Andrew Morton wrote:
>>>
>>>
>>> That's the sort of thing we'd prefer to avoid.
>>>
>>>
>>> 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.
> 
> Ah. So there's no real bug upstream, right?

Matches my understanding.

> 
> And I am not sure it is how we want to address this. I don't think we
> should allow randomly map huge zero page (and non-huge too). It can be a
> security risk if it ever gets exposed writable.

Due to some DAX stuff (and others) we have the shared zeropage in VM_MIXEDMAP.
And we have some elaborate checks in vm_mixed_zeropage_allowed() to test for that.

We should do a similar validation, and ideally just forbid it if not used yet.

-- 
Cheers,

David

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

[Andrew Morton]

On Mon, 14 Sep 2026 16:29:00 +0200 "David Hildenbrand (Arm)" <david@kernel.org> wrote:

> On 9/14/26 12:59, Kiryl Shutsemau wrote:
> > On Sun, Sep 13, 2026 at 03:23:12PM +0800, Lance Yang wrote:
> >>
> >> On Sat, Sep 12, 2026 at 11:46:35PM -0700, Andrew Morton wrote:
> >>>
> >>>
> >>> That's the sort of thing we'd prefer to avoid.
> >>>
> >>>
> >>> 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.
> > 
> > Ah. So there's no real bug upstream, right?
> 
> Matches my understanding.

Thanks.  I'll remove cc:stable, move this into mm-unstable as a
next-merge-window thing.

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

[Lance Yang]

On 2026/9/15 02:19, Andrew Morton wrote:
> On Mon, 14 Sep 2026 16:29:00 +0200 "David Hildenbrand (Arm)" <david@kernel.org> wrote:
> 
>> On 9/14/26 12:59, Kiryl Shutsemau wrote:
>>> On Sun, Sep 13, 2026 at 03:23:12PM +0800, Lance Yang wrote:
>>>>
>>>> On Sat, Sep 12, 2026 at 11:46:35PM -0700, Andrew Morton wrote:
>>>>>
>>>>>
>>>>> That's the sort of thing we'd prefer to avoid.
>>>>>
>>>>>
>>>>> 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.
>>>
>>> Ah. So there's no real bug upstream, right?
>>
>> Matches my understanding.
> 
> Thanks.  I'll remove cc:stable, move this into mm-unstable as a
> next-merge-window thing.

Sounds good to me, thanks, Andrew!

Kiryl, David, would you prefer the validation for raw-PFN mappings
of the huge zero page as a separate follow-up, or should that
validation replace this patch? wdyt

Cheers, Lance

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

[Kiryl Shutsemau]

On Tue, Sep 15, 2026 at 09:43:15PM +0800, Lance Yang wrote:
> 
> 
> On 2026/9/15 02:19, Andrew Morton wrote:
> > On Mon, 14 Sep 2026 16:29:00 +0200 "David Hildenbrand (Arm)" <david@kernel.org> wrote:
> > 
> > > On 9/14/26 12:59, Kiryl Shutsemau wrote:
> > > > On Sun, Sep 13, 2026 at 03:23:12PM +0800, Lance Yang wrote:
> > > > > 
> > > > > On Sat, Sep 12, 2026 at 11:46:35PM -0700, Andrew Morton wrote:
> > > > > > 
> > > > > > 
> > > > > > That's the sort of thing we'd prefer to avoid.
> > > > > > 
> > > > > > 
> > > > > > 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.
> > > > 
> > > > Ah. So there's no real bug upstream, right?
> > > 
> > > Matches my understanding.
> > 
> > Thanks.  I'll remove cc:stable, move this into mm-unstable as a
> > next-merge-window thing.
> 
> Sounds good to me, thanks, Andrew!
> 
> Kiryl, David, would you prefer the validation for raw-PFN mappings
> of the huge zero page as a separate follow-up, or should that
> validation replace this patch? wdyt

I think this patch can be useful for graceful recovery if we somehow ended up
with a zero page in a mapping where we shouldn't have one.

A separate patch with validation would be great.

-- 
  Kiryl Shutsemau / Kirill A. Shutemov

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

[David Hildenbrand (Arm)]

On 9/15/26 15:52, Kiryl Shutsemau wrote:
> On Tue, Sep 15, 2026 at 09:43:15PM +0800, Lance Yang wrote:
>>
>>
>> On 2026/9/15 02:19, Andrew Morton wrote:
>>>
>>>
>>> Thanks.  I'll remove cc:stable, move this into mm-unstable as a
>>> next-merge-window thing.
>>
>> Sounds good to me, thanks, Andrew!
>>
>> Kiryl, David, would you prefer the validation for raw-PFN mappings
>> of the huge zero page as a separate follow-up, or should that
>> validation replace this patch? wdyt
> 
> I think this patch can be useful for graceful recovery if we somehow ended up
> with a zero page in a mapping where we shouldn't have one.
> 
> A separate patch with validation would be great.
> 

Ack

-- 
Cheers,

David

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

[David Hildenbrand (Arm)]

On 9/13/26 07:19, Lance Yang 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.
> 
> 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
> Signed-off-by: Lance Yang <lance.yang@linux.dev>
> ---
>  mm/huge_memory.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index 6895b38e4704..0ed997a97416 100644
> --- 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


Ok, it's really only DAX and anonymous VMAs that use the huge zero folio. Other
(module) code would have a hard time using it, as mm_get_huge_zero_folio() is
not exported to modules.

DAX uses dax_pmd_load_hole()->vmf_insert_folio_pmd()->insert_pmd() where we
deposit a page table only if arch_needs_pgtable_deposit().


So I think the rule is simply:

arch_needs_pgtable_deposit() -> always deposited
vma_is_anonymous() -> always deposited

?

The trick is that we don't have anon THPs in non-anon VMAs.

So could this be simplified further or am I missing something?

-- 
Cheers,

David