Re: [PATCH] mm/migrate_device: avoid overflowing migrate_vma collection arrays

[David Hildenbrand (Arm)]

On 7/10/26 13:30, Zi Yan wrote:
> On Wed Jul 8, 2026 at 10:43 AM EDT, Zi Yan wrote:
>> On Wed Jul 8, 2026 at 10:35 AM EDT, Zi Yan wrote:
>>>
>>> I guess I have the same feelings.
>>>
>>> You mean we reset migrate->cpages and migrate->npages and restart from
>>> the beginning? But it is not only that, since the code below also
>>> changes PTEs into migration entries. We will need to revert them as
>>> well.
>>>
>>> Hmm, migrate_vma_collect() documents itself as "update the src array and
>>> "takes a reference on the page" without mentioning changing PTEs. I
>>> wonder why changing PTEs is necessary, since later migrate_vma_unmap()
>>> also changes page table entries to migration entries, although
>>> migrate_vma_unmap() changes all entries to a folio, whereas
>>> migrate_vma_collect() only changes PTEs from the specified VMA.
>>
>> OK, it is an optimization[1] when migrate_vma*() was introduced. If
>> there is only one mapping, migrate_vma_collect() will set migration
>> entry immediately without waiting until migrate_vma_unmap(). Fun.
>>
>> [1] Commit 8c3328f1f36a5 ("mm/migrate: migrate_vma() unmap page from vma while collecting pages")
> 
> Hi David,
> 

Hi,

> Do you think this patch is good to get in? I would like to get ack from
> you.

I dislike that we fail collecting even though there is something (different)
mapped now.

In case we stumble over a PMD, there sure are no migration entries on the PTE
level anymore?

-- 
Cheers,

David