Re: [PATCH] mm/migrate_device: fix cache flush when replacing huge zero PMD

On Mon, 17 Aug 2026 17:35:53 +1000 Balbir Singh <[email protected]> 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 <[email protected]>
> > ---
> >  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 <[email protected]>

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?