Re: [PATCH] mm/migrate_device: fix cache flush when replacing huge zero PMD
From: Andrew Morton
Date: Mon Aug 17 2026 - 12:08:49 EST
On Mon, 17 Aug 2026 17:35:53 +1000 Balbir Singh <balbirs@xxxxxxxxxx> wrote:
> On 8/17/26 4:08 PM, Hui Su wrote:
> > 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.
> >
> > Fixes: a30b48bf1b24 ("mm/migrate_device: implement THP migration of zone device pages")
> > Signed-off-by: Hui Su <sh_def@xxxxxxx>
> > ---
> > mm/migrate_device.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/mm/migrate_device.c b/mm/migrate_device.c
> > index 908d2d4ec43a..098c04c1b124 100644
> > --- a/mm/migrate_device.c
> > +++ b/mm/migrate_device.c
> > @@ -872,7 +872,7 @@ static int migrate_vma_insert_huge_pmd_page(struct migrate_vma *migrate,
> >
> > 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);
>
> Reviewed-by: Balbir Singh <balbirs@xxxxxxxxxx>
doh. It's a shame this actually compiled...
Can we add some speculation about the userspace-visible effects of the
bug?
I'm assuming we should backport the fix?