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

[Andrew Morton]

On Tue, 18 Aug 2026 00:36:46 +0800 Hui Su <sh_def@xxxxxxx> wrote:

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

OK, thanks for checking.

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

Yes please, after 7.3-rc1.