[PATCHv2] mm/huge_memory: set the mmu_gather page size in zap_huge_pud()

[PATCHv2] mm/huge_memory: set the mmu_gather page size in zap_huge_pud()

[Ritesh Harjani (IBM)]

Unmapping a device-dax mapping with 1G alignment on powerpc radix kernel
built with CONFIG_DEBUG_VM triggers this warning on every munmap:

    WARNING: mm/mmu_gather.c:176 at __tlb_remove_folio_pages_size+0x38/0x230
    NIP [c00000000063d508] __tlb_remove_folio_pages_size+0x38/0x230
    LR [c0000000006fb688] zap_huge_pud+0x1b8/0x2d0
    Call Trace:
     zap_huge_pud+0x170/0x2d0 (unreliable)
     __zap_vma_range+0x1604/0x1e20
     unmap_vmas+0xa0/0x1f0
     unmap_region+0xb0/0x130
     vms_complete_munmap_vmas+0x120/0x310
     do_vmi_align_munmap+0x1ec/0x240
     __vm_munmap+0x148/0x220
     sys_munmap+0x28/0x40

To trigger this - it is enough to mmap() /dev/dax0.0, touch the first
byte so that the whole 1G is mapped by a single PUD and then munmap()
it.

PowerPC needs MMU_GATHER_PAGE_SIZE in which mmu_gather needs to record
the page size for which tlb flush is needed. zap_huge_pmd(),
zap_pte_range(), change_huge_pud() etc all do this already. However,
since commit:
  dbe54153296d ("mm/huge_memory: add vmf_insert_folio_pud()")

a device-dax PUD maps a real folio and zap_huge_pud() now hands it to
tlb_remove_page_size(tlb, page, HPAGE_PUD_SIZE). At that point
tlb->page_size is still whatever the previous user left behind, which is
0 for the fresh gather set up by munmap() and so the check fires.

Fix this in the same way like how other similar paths do.

Fixes: dbe54153296d0 ("mm/huge_memory: add vmf_insert_folio_pud()")
Reported-by: Pavithra <pavrampu@linux.ibm.com>
Signed-off-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
---
[v1]->v2:
=========
- Split the 2 part patch series. Patch-1 is now superseded by a different patch
  from Muchun which he already posted [2].
- No difference in this patch from v1.

[v1]: https://lore.kernel.org/all/97f85592bb78a273be8519e6897e7f9b9bd31469.1793070429.git.ritesh.list@gmail.com/
[2]: https://lore.kernel.org/all/20261029063601.1961415-1-songmuchun@bytedance.com/

 mm/huge_memory.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index bd44d58e8684..7e589a2fb02d 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -3040,6 +3040,8 @@ int zap_huge_pud(struct mmu_gather *tlb, struct vm_area_struct *vma,
 	spinlock_t *ptl;
 	pud_t orig_pud;

+	tlb_change_page_size(tlb, HPAGE_PUD_SIZE);
+
 	ptl = __pud_trans_huge_lock(pud, vma);
 	if (!ptl)
 		return 0;
--
2.39.5

Re: [PATCHv2] mm/huge_memory: set the mmu_gather page size in zap_huge_pud()

[Zi Yan]

On 29 Oct 2026, at 20:07, Ritesh Harjani (IBM) wrote:

> Unmapping a device-dax mapping with 1G alignment on powerpc radix kernel
> built with CONFIG_DEBUG_VM triggers this warning on every munmap:
>
>     WARNING: mm/mmu_gather.c:176 at __tlb_remove_folio_pages_size+0x38/0x230
>     NIP [c00000000063d508] __tlb_remove_folio_pages_size+0x38/0x230
>     LR [c0000000006fb688] zap_huge_pud+0x1b8/0x2d0
>     Call Trace:
>      zap_huge_pud+0x170/0x2d0 (unreliable)
>      __zap_vma_range+0x1604/0x1e20
>      unmap_vmas+0xa0/0x1f0
>      unmap_region+0xb0/0x130
>      vms_complete_munmap_vmas+0x120/0x310
>      do_vmi_align_munmap+0x1ec/0x240
>      __vm_munmap+0x148/0x220
>      sys_munmap+0x28/0x40
>
> To trigger this - it is enough to mmap() /dev/dax0.0, touch the first
> byte so that the whole 1G is mapped by a single PUD and then munmap()
> it.
>
> PowerPC needs MMU_GATHER_PAGE_SIZE in which mmu_gather needs to record
> the page size for which tlb flush is needed. zap_huge_pmd(),
> zap_pte_range(), change_huge_pud() etc all do this already. However,
> since commit:
>   dbe54153296d ("mm/huge_memory: add vmf_insert_folio_pud()")
>
> a device-dax PUD maps a real folio and zap_huge_pud() now hands it to
> tlb_remove_page_size(tlb, page, HPAGE_PUD_SIZE). At that point
> tlb->page_size is still whatever the previous user left behind, which is
> 0 for the fresh gather set up by munmap() and so the check fires.
>
> Fix this in the same way like how other similar paths do.
>
> Fixes: dbe54153296d0 ("mm/huge_memory: add vmf_insert_folio_pud()")
> Reported-by: Pavithra <pavrampu@linux.ibm.com>
> Signed-off-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
> ---
> [v1]->v2:
> =========
> - Split the 2 part patch series. Patch-1 is now superseded by a different patch
>   from Muchun which he already posted [2].
> - No difference in this patch from v1.
>
> [v1]: https://lore.kernel.org/all/97f85592bb78a273be8519e6897e7f9b9bd31469.1793070429.git.ritesh.list@gmail.com/
> [2]: https://lore.kernel.org/all/20261029063601.1961415-1-songmuchun@bytedance.com/
>
>  mm/huge_memory.c | 2 ++
>  1 file changed, 2 insertions(+)
>

Makes sense. Thanks.

Acked-by: Zi Yan <ziy@nvidia.com>


Best Regards,
Yan, Zi

Re: [PATCHv2] mm/huge_memory: set the mmu_gather page size in zap_huge_pud()

[Muchun Song]

> On Oct 30, 2026, at 08:07, Ritesh Harjani (IBM) <ritesh.list@gmail.com> wrote:
> 
> Unmapping a device-dax mapping with 1G alignment on powerpc radix kernel
> built with CONFIG_DEBUG_VM triggers this warning on every munmap:
> 
>    WARNING: mm/mmu_gather.c:176 at __tlb_remove_folio_pages_size+0x38/0x230
>    NIP [c00000000063d508] __tlb_remove_folio_pages_size+0x38/0x230
>    LR [c0000000006fb688] zap_huge_pud+0x1b8/0x2d0
>    Call Trace:
>     zap_huge_pud+0x170/0x2d0 (unreliable)
>     __zap_vma_range+0x1604/0x1e20
>     unmap_vmas+0xa0/0x1f0
>     unmap_region+0xb0/0x130
>     vms_complete_munmap_vmas+0x120/0x310
>     do_vmi_align_munmap+0x1ec/0x240
>     __vm_munmap+0x148/0x220
>     sys_munmap+0x28/0x40
> 
> To trigger this - it is enough to mmap() /dev/dax0.0, touch the first
> byte so that the whole 1G is mapped by a single PUD and then munmap()
> it.
> 
> PowerPC needs MMU_GATHER_PAGE_SIZE in which mmu_gather needs to record
> the page size for which tlb flush is needed. zap_huge_pmd(),
> zap_pte_range(), change_huge_pud() etc all do this already. However,
> since commit:
>  dbe54153296d ("mm/huge_memory: add vmf_insert_folio_pud()")
> 
> a device-dax PUD maps a real folio and zap_huge_pud() now hands it to
> tlb_remove_page_size(tlb, page, HPAGE_PUD_SIZE). At that point
> tlb->page_size is still whatever the previous user left behind, which is
> 0 for the fresh gather set up by munmap() and so the check fires.
> 
> Fix this in the same way like how other similar paths do.
> 
> Fixes: dbe54153296d0 ("mm/huge_memory: add vmf_insert_folio_pud()")
> Reported-by: Pavithra <pavrampu@linux.ibm.com>
> Signed-off-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>

Acked-by: Muchun Song <muchun.song@linux.dev>

Thanks.

Re: [PATCHv2] mm/huge_memory: set the mmu_gather page size in zap_huge_pud()

[pavrampu]

On 2026-10-30 05:37, Ritesh Harjani (IBM) wrote:
> Unmapping a device-dax mapping with 1G alignment on powerpc radix 
> kernel
> built with CONFIG_DEBUG_VM triggers this warning on every munmap:
> 
>     WARNING: mm/mmu_gather.c:176 at 
> __tlb_remove_folio_pages_size+0x38/0x230
>     NIP [c00000000063d508] __tlb_remove_folio_pages_size+0x38/0x230
>     LR [c0000000006fb688] zap_huge_pud+0x1b8/0x2d0
>     Call Trace:
>      zap_huge_pud+0x170/0x2d0 (unreliable)
>      __zap_vma_range+0x1604/0x1e20
>      unmap_vmas+0xa0/0x1f0
>      unmap_region+0xb0/0x130
>      vms_complete_munmap_vmas+0x120/0x310
>      do_vmi_align_munmap+0x1ec/0x240
>      __vm_munmap+0x148/0x220
>      sys_munmap+0x28/0x40
> 
> To trigger this - it is enough to mmap() /dev/dax0.0, touch the first
> byte so that the whole 1G is mapped by a single PUD and then munmap()
> it.
> 
> PowerPC needs MMU_GATHER_PAGE_SIZE in which mmu_gather needs to record
> the page size for which tlb flush is needed. zap_huge_pmd(),
> zap_pte_range(), change_huge_pud() etc all do this already. However,
> since commit:
>   dbe54153296d ("mm/huge_memory: add vmf_insert_folio_pud()")
> 
> a device-dax PUD maps a real folio and zap_huge_pud() now hands it to
> tlb_remove_page_size(tlb, page, HPAGE_PUD_SIZE). At that point
> tlb->page_size is still whatever the previous user left behind, which 
> is
> 0 for the fresh gather set up by munmap() and so the check fires.
> 
> Fix this in the same way like how other similar paths do.
> 
> Fixes: dbe54153296d0 ("mm/huge_memory: add vmf_insert_folio_pud()")
> Reported-by: Pavithra <pavrampu@linux.ibm.com>
> Signed-off-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
> ---
> [v1]->v2:
> =========
> - Split the 2 part patch series. Patch-1 is now superseded by a 
> different patch
>   from Muchun which he already posted [2].
> - No difference in this patch from v1.
> 
> [v1]:
> https://lore.kernel.org/all/97f85592bb78a273be8519e6897e7f9b9bd31469.1793070429.git.ritesh.list@gmail.com/
> [2]:
> https://lore.kernel.org/all/20261029063601.1961415-1-songmuchun@bytedance.com/
> 
>  mm/huge_memory.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index bd44d58e8684..7e589a2fb02d 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -3040,6 +3040,8 @@ int zap_huge_pud(struct mmu_gather *tlb, struct
> vm_area_struct *vma,
>  	spinlock_t *ptl;
>  	pud_t orig_pud;
> 
> +	tlb_change_page_size(tlb, HPAGE_PUD_SIZE);
> +
>  	ptl = __pud_trans_huge_lock(pud, vma);
>  	if (!ptl)
>  		return 0;
> --
> 2.39.5

Tested on Power10 (ppc64le), kernel v7.3

Tested-by: Pavithra Prakash <pavrampu@linux.ibm.com>

Re: [PATCHv2] mm/huge_memory: set the mmu_gather page size in zap_huge_pud()

[David Hildenbrand (Arm)]

On 10/30/26 01:07, Ritesh Harjani (IBM) wrote:
> Unmapping a device-dax mapping with 1G alignment on powerpc radix kernel
> built with CONFIG_DEBUG_VM triggers this warning on every munmap:
> 
>     WARNING: mm/mmu_gather.c:176 at __tlb_remove_folio_pages_size+0x38/0x230
>     NIP [c00000000063d508] __tlb_remove_folio_pages_size+0x38/0x230
>     LR [c0000000006fb688] zap_huge_pud+0x1b8/0x2d0
>     Call Trace:
>      zap_huge_pud+0x170/0x2d0 (unreliable)
>      __zap_vma_range+0x1604/0x1e20
>      unmap_vmas+0xa0/0x1f0
>      unmap_region+0xb0/0x130
>      vms_complete_munmap_vmas+0x120/0x310
>      do_vmi_align_munmap+0x1ec/0x240
>      __vm_munmap+0x148/0x220
>      sys_munmap+0x28/0x40
> 
> To trigger this - it is enough to mmap() /dev/dax0.0, touch the first
> byte so that the whole 1G is mapped by a single PUD and then munmap()
> it.
> 
> PowerPC needs MMU_GATHER_PAGE_SIZE in which mmu_gather needs to record
> the page size for which tlb flush is needed. zap_huge_pmd(),
> zap_pte_range(), change_huge_pud() etc all do this already. However,
> since commit:
>   dbe54153296d ("mm/huge_memory: add vmf_insert_folio_pud()")
> 
> a device-dax PUD maps a real folio and zap_huge_pud() now hands it to
> tlb_remove_page_size(tlb, page, HPAGE_PUD_SIZE). At that point
> tlb->page_size is still whatever the previous user left behind, which is
> 0 for the fresh gather set up by munmap() and so the check fires.
> 
> Fix this in the same way like how other similar paths do.
> 
> Fixes: dbe54153296d0 ("mm/huge_memory: add vmf_insert_folio_pud()")
> Reported-by: Pavithra <pavrampu@linux.ibm.com>
> Signed-off-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
> ---
> [v1]->v2:
> =========
> - Split the 2 part patch series. Patch-1 is now superseded by a different patch
>   from Muchun which he already posted [2].
> - No difference in this patch from v1.
> 
> [v1]: https://lore.kernel.org/all/97f85592bb78a273be8519e6897e7f9b9bd31469.1793070429.git.ritesh.list@gmail.com/
> [2]: https://lore.kernel.org/all/20261029063601.1961415-1-songmuchun@bytedance.com/
> 
>  mm/huge_memory.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index bd44d58e8684..7e589a2fb02d 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -3040,6 +3040,8 @@ int zap_huge_pud(struct mmu_gather *tlb, struct vm_area_struct *vma,
>  	spinlock_t *ptl;
>  	pud_t orig_pud;
> 
> +	tlb_change_page_size(tlb, HPAGE_PUD_SIZE);
> +
>  	ptl = __pud_trans_huge_lock(pud, vma);
>  	if (!ptl)
>  		return 0;
> --
> 2.39.5
> 


Matches zap_huge_pmd().

I will wait a bit  and then queue this shortly.

This sounds like stable material?

-- 
Cheers,

David

Re: [PATCHv2] mm/huge_memory: set the mmu_gather page size in zap_huge_pud()

[Ritesh Harjani]

"David Hildenbrand (Arm)" <david@kernel.org> writes:

> On 10/30/26 01:07, Ritesh Harjani (IBM) wrote:
>> Unmapping a device-dax mapping with 1G alignment on powerpc radix kernel
>> built with CONFIG_DEBUG_VM triggers this warning on every munmap:
>> 
>>     WARNING: mm/mmu_gather.c:176 at __tlb_remove_folio_pages_size+0x38/0x230
>>     NIP [c00000000063d508] __tlb_remove_folio_pages_size+0x38/0x230
>>     LR [c0000000006fb688] zap_huge_pud+0x1b8/0x2d0
>>     Call Trace:
>>      zap_huge_pud+0x170/0x2d0 (unreliable)
>>      __zap_vma_range+0x1604/0x1e20
>>      unmap_vmas+0xa0/0x1f0
>>      unmap_region+0xb0/0x130
>>      vms_complete_munmap_vmas+0x120/0x310
>>      do_vmi_align_munmap+0x1ec/0x240
>>      __vm_munmap+0x148/0x220
>>      sys_munmap+0x28/0x40
>> 
>> To trigger this - it is enough to mmap() /dev/dax0.0, touch the first
>> byte so that the whole 1G is mapped by a single PUD and then munmap()
>> it.
>> 
>> PowerPC needs MMU_GATHER_PAGE_SIZE in which mmu_gather needs to record
>> the page size for which tlb flush is needed. zap_huge_pmd(),
>> zap_pte_range(), change_huge_pud() etc all do this already. However,
>> since commit:
>>   dbe54153296d ("mm/huge_memory: add vmf_insert_folio_pud()")
>> 
>> a device-dax PUD maps a real folio and zap_huge_pud() now hands it to
>> tlb_remove_page_size(tlb, page, HPAGE_PUD_SIZE). At that point
>> tlb->page_size is still whatever the previous user left behind, which is
>> 0 for the fresh gather set up by munmap() and so the check fires.
>> 
>> Fix this in the same way like how other similar paths do.
>> 
>> Fixes: dbe54153296d0 ("mm/huge_memory: add vmf_insert_folio_pud()")
>> Reported-by: Pavithra <pavrampu@linux.ibm.com>
>> Signed-off-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
>> ---
>> [v1]->v2:
>> =========
>> - Split the 2 part patch series. Patch-1 is now superseded by a different patch
>>   from Muchun which he already posted [2].
>> - No difference in this patch from v1.
>> 
>> [v1]: https://lore.kernel.org/all/97f85592bb78a273be8519e6897e7f9b9bd31469.1793070429.git.ritesh.list@gmail.com/
>> [2]: https://lore.kernel.org/all/20261029063601.1961415-1-songmuchun@bytedance.com/
>> 
>>  mm/huge_memory.c | 2 ++
>>  1 file changed, 2 insertions(+)
>> 
>> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
>> index bd44d58e8684..7e589a2fb02d 100644
>> --- a/mm/huge_memory.c
>> +++ b/mm/huge_memory.c
>> @@ -3040,6 +3040,8 @@ int zap_huge_pud(struct mmu_gather *tlb, struct vm_area_struct *vma,
>>  	spinlock_t *ptl;
>>  	pud_t orig_pud;
>> 
>> +	tlb_change_page_size(tlb, HPAGE_PUD_SIZE);
>> +
>>  	ptl = __pud_trans_huge_lock(pud, vma);
>>  	if (!ptl)
>>  		return 0;
>> --
>> 2.39.5
>> 
>
>
> Matches zap_huge_pmd().
>
> I will wait a bit  and then queue this shortly.
>

Thanks David, however, looks like Andrew might have queued this up in
his mm tree [1], right?

[1]: https://lore.kernel.org/all/20261030021905.2DCA71F000C1@smtp.kernel.org/

> This sounds like stable material?
>

Sorry, my bad. Yes, we should have this Cc: stable@vger.kernel.org.

Kindly let me know if I should update the tag and send v3, or can it be
taken care? Thanks!

-ritesh

Re: [PATCHv2] mm/huge_memory: set the mmu_gather page size in zap_huge_pud()

[David Hildenbrand (Arm)]

On 10/30/26 11:15, Ritesh Harjani (IBM) wrote:
> "David Hildenbrand (Arm)" <david@kernel.org> writes:
> 
>> On 10/30/26 01:07, Ritesh Harjani (IBM) wrote:
>>> Unmapping a device-dax mapping with 1G alignment on powerpc radix kernel
>>> built with CONFIG_DEBUG_VM triggers this warning on every munmap:
>>>
>>>     WARNING: mm/mmu_gather.c:176 at __tlb_remove_folio_pages_size+0x38/0x230
>>>     NIP [c00000000063d508] __tlb_remove_folio_pages_size+0x38/0x230
>>>     LR [c0000000006fb688] zap_huge_pud+0x1b8/0x2d0
>>>     Call Trace:
>>>      zap_huge_pud+0x170/0x2d0 (unreliable)
>>>      __zap_vma_range+0x1604/0x1e20
>>>      unmap_vmas+0xa0/0x1f0
>>>      unmap_region+0xb0/0x130
>>>      vms_complete_munmap_vmas+0x120/0x310
>>>      do_vmi_align_munmap+0x1ec/0x240
>>>      __vm_munmap+0x148/0x220
>>>      sys_munmap+0x28/0x40
>>>
>>> To trigger this - it is enough to mmap() /dev/dax0.0, touch the first
>>> byte so that the whole 1G is mapped by a single PUD and then munmap()
>>> it.
>>>
>>> PowerPC needs MMU_GATHER_PAGE_SIZE in which mmu_gather needs to record
>>> the page size for which tlb flush is needed. zap_huge_pmd(),
>>> zap_pte_range(), change_huge_pud() etc all do this already. However,
>>> since commit:
>>>   dbe54153296d ("mm/huge_memory: add vmf_insert_folio_pud()")
>>>
>>> a device-dax PUD maps a real folio and zap_huge_pud() now hands it to
>>> tlb_remove_page_size(tlb, page, HPAGE_PUD_SIZE). At that point
>>> tlb->page_size is still whatever the previous user left behind, which is
>>> 0 for the fresh gather set up by munmap() and so the check fires.
>>>
>>> Fix this in the same way like how other similar paths do.
>>>
>>> Fixes: dbe54153296d0 ("mm/huge_memory: add vmf_insert_folio_pud()")
>>> Reported-by: Pavithra <pavrampu@linux.ibm.com>
>>> Signed-off-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
>>> ---
>>> [v1]->v2:
>>> =========
>>> - Split the 2 part patch series. Patch-1 is now superseded by a different patch
>>>   from Muchun which he already posted [2].
>>> - No difference in this patch from v1.
>>>
>>> [v1]: https://lore.kernel.org/all/97f85592bb78a273be8519e6897e7f9b9bd31469.1793070429.git.ritesh.list@gmail.com/
>>> [2]: https://lore.kernel.org/all/20261029063601.1961415-1-songmuchun@bytedance.com/
>>>
>>>  mm/huge_memory.c | 2 ++
>>>  1 file changed, 2 insertions(+)
>>>
>>> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
>>> index bd44d58e8684..7e589a2fb02d 100644
>>> --- a/mm/huge_memory.c
>>> +++ b/mm/huge_memory.c
>>> @@ -3040,6 +3040,8 @@ int zap_huge_pud(struct mmu_gather *tlb, struct vm_area_struct *vma,
>>>  	spinlock_t *ptl;
>>>  	pud_t orig_pud;
>>>
>>> +	tlb_change_page_size(tlb, HPAGE_PUD_SIZE);
>>> +
>>>  	ptl = __pud_trans_huge_lock(pud, vma);
>>>  	if (!ptl)
>>>  		return 0;
>>> --
>>> 2.39.5
>>>
>>
>>
>> Matches zap_huge_pmd().
>>
>> I will wait a bit  and then queue this shortly.
>>
> 
> Thanks David, however, looks like Andrew might have queued this up in
> his mm tree [1], right?
> 
> [1]: https://lore.kernel.org/all/20261030021905.2DCA71F000C1@smtp.kernel.org/

No worries, one of us can drop it before sending it upstream.

I'm about to send out the MAINTAINTERS update in a bit, so right now it's still
confusing.

(but also there is no harm in having it in two trees temporarily)

> 
>> This sounds like stable material?
>>
> 
> Sorry, my bad. Yes, we should have this Cc: stable@vger.kernel.org.
> 
> Kindly let me know if I should update the tag and send v3, or can it be
> taken care? Thanks!

I would just apply that when picking, no need to resend.

Thanks!

-- 
Cheers,

David

Re: [PATCHv2] mm/huge_memory: set the mmu_gather page size in zap_huge_pud()

[David Hildenbrand]

On Fri, 30 Oct 2026 05:37:36 +0530, Ritesh Harjani (IBM) wrote:
> Unmapping a device-dax mapping with 1G alignment on powerpc radix kernel
> built with CONFIG_DEBUG_VM triggers this warning on every munmap:
> 
>     WARNING: mm/mmu_gather.c:176 at __tlb_remove_folio_pages_size+0x38/0x230
>     NIP [c00000000063d508] __tlb_remove_folio_pages_size+0x38/0x230
>     LR [c0000000006fb688] zap_huge_pud+0x1b8/0x2d0
>     Call Trace:
>      zap_huge_pud+0x170/0x2d0 (unreliable)
>      __zap_vma_range+0x1604/0x1e20
>      unmap_vmas+0xa0/0x1f0
>      unmap_region+0xb0/0x130
>      vms_complete_munmap_vmas+0x120/0x310
>      do_vmi_align_munmap+0x1ec/0x240
>      __vm_munmap+0x148/0x220
>      sys_munmap+0x28/0x40
> 
> [...]

Applied, thanks!

tree: mm/core.git
branch: for-next-fixes

Applied patches will appear soon in mm-next, followed by linux-next.

Please report any outstanding bugs that were missed during review, so we
can either drop the patch series or decide how to fix it up.

It is encouraged to provide Acked-bys, Reviewed-bys, and Tested-bys even
though the patches have already been applied. If possible, patch trailers
will be updated.

Note that commit hashes shown below are subject to change due to rebase,
trailer updates or similar. Further, this is not a guarantee that the
patches will go upstream. If in doubt, please check the listed branch.

[1/1] mm/huge_memory: set the mmu_gather page size in zap_huge_pud()
      https://git.kernel.org/mm/core/c/0ba86a16

-- 
Cheers,

David