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

Balbir Singh <[email protected]>
Newsgroups gmane.linux.kernel,gmane.linux.kernel.mm
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.