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

[Balbir Singh <balbirs@nvidia.com>]

On 8/18/26 7:34 AM, Andrew Morton wrote:
> On Tue, 18 Aug 2026 00:36:46 +0800 Hui Su <sh_def@163.com> 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@nvidia.com>
>>>
>>> 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