Re: [PATCH] mm/migrate_device: fix cache flush when replacing huge zero PMD
Balbir Singh <[email protected]>
| Newsgroups | org.kvack.linux-mm,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
On 8/18/26 7:34 AM, Andrew Morton wrote: > On Tue, 18 Aug 2026 00:36:46 +0800 Hui Su <[email protected]> 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 <[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? >> >> 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. I have been running some tests at my end, I have some new ones, nothing so far exposes this. Thanks for checking Hui! Balbir