+ mm-migrate_device-fix-cache-flush-when-replacing-huge-zero-pmd.patch added to mm-unstable branch

The patch titled
     Subject: mm/migrate_device: fix cache flush when replacing huge zero PMD
has been added to the -mm mm-unstable branch.  Its filename is
     mm-migrate_device-fix-cache-flush-when-replacing-huge-zero-pmd.patch

This patch will shortly appear at
     https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/mm-migrate_device-fix-cache-flush-when-replacing-huge-zero-pmd.patch

This patch will later appear in the mm-unstable branch at
    git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm

Before you just go and hit "reply", please:
   a) Consider who else should be cc'ed
   b) Prefer to cc a suitable mailing list as well
   c) Ideally: find the original patch on the mailing list and do a
      reply-to-all to that, adding suitable additional cc's

*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***

The -mm tree is included into linux-next via various
branches at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
and is updated there most days

------------------------------------------------------
From: Hui Su <[email protected]>
Subject: mm/migrate_device: fix cache flush when replacing huge zero PMD
Date: Mon, 17 Aug 2026 14:08:46 +0800

migrate_vma_insert_huge_pmd_page() calls flush_cache_page() before
replacing an existing huge zero PMD.  However, the third argument to
flush_cache_page() is a PFN, while addr + HPAGE_PMD_SIZE is an end virtual
address.

More importantly, the mapping being invalidated is PMD-sized rather than
PAGE_SIZE-sized.  Flush the whole PMD range with flush_cache_range(),
matching other huge PMD invalidation paths.

There is no userspace-visible effect today.  The architectures that
currently enable ARCH_ENABLE_THP_MIGRATION use no-op implementations of
flush_cache_page()/flush_cache_range().  32-bit ARM has non-trivial
implementations, but does not enable ARCH_ENABLE_THP_MIGRATION.

So this appears to be a latent API misuse rather than a currently
observable bug, and I don't think a stable backport is necessary.

Link: https://lore.kernel.org/[email protected]
Fixes: a30b48bf1b24 ("mm/migrate_device: implement THP migration of zone device pages")
Signed-off-by: Hui Su <[email protected]>
Reviewed-by: Balbir Singh <[email protected]>
Reviewed-by: Zi Yan <[email protected]>
Acked-by: David Hildenbrand (Arm) <[email protected]>
Cc: Alistair Popple <[email protected]>
Cc: Byungchul Park <[email protected]>
Cc: Gregory Price <[email protected]>
Cc: "Huang, Ying" <[email protected]>
Cc: Joshua Hahn <[email protected]>
Cc: Matthew Brost <[email protected]>
Cc: Rakie Kim <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
---

 mm/migrate_device.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/mm/migrate_device.c~mm-migrate_device-fix-cache-flush-when-replacing-huge-zero-pmd
+++ a/mm/migrate_device.c
@@ -882,7 +882,7 @@ static int migrate_vma_insert_huge_pmd_p
 
 	if (flush) {
 		pte_free(vma->vm_mm, pgtable);
-		flush_cache_page(vma, addr, addr + HPAGE_PMD_SIZE);
+		flush_cache_range(vma, addr, addr + HPAGE_PMD_SIZE);
 		pmdp_invalidate(vma, addr, pmdp);
 	} else {
 		pgtable_trans_huge_deposit(vma->vm_mm, pmdp, pgtable);
_

Patches currently in -mm which might be from [email protected] are

mm-migrate_device-avoid-out-of-bounds-writes-for-compound-folios.patch
kasan-fix-cache-shrink-race-with-cpu-hotplug.patch
kasan-fix-quarantine_size-accounting-during-cache-removal.patch
mm-migrate_device-fix-cache-flush-when-replacing-huge-zero-pmd.patch