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

On 10/30/26 11:15, Ritesh Harjani (IBM) wrote:

"David Hildenbrand (Arm)" [off-list ref] writes:

quoted

On 10/30/26 01:07, Ritesh Harjani (IBM) wrote:

quoted

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 <redacted>
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/ (local)
[2]: https://lore.kernel.org/all/20261029063601.1961415-1-songmuchun@bytedance.com/ (local)

 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/ (local)

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)

quoted

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