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

[Hui Su]

> 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?

Hi,

I took a closer look at this, 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.

Should I resend a v2 clarifying the userspace-visible effect in the
changelog?

Thanks,
Hui