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

["Zi Yan" <ziy@nvidia.com>]

On Fri Jul 10, 2026 at 7:56 AM EDT, David Hildenbrand (Arm) wrote:
> 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.

Not all the time. After a folio split and PTE lock is dropped, there are
different cases:

1. no page table change, the collection grabs the PTE lock and continues;

2. some PTE(s) is changed, the same as 1 and the collection continues;

3. the PMD pointing to the PTE page table is changed to either a leaf
   PMD or an invalid PMD, the collection cannot grab the PTE lock to
   work on the remaming PTEs, since they are gone. For the collected
   PFNs (they are mapped more than once) and folios with elevated
   refcount (they are mapped once and unmapped here as an optimization),
   they will be processed later in migrate_vma_unmap(). Since
   migrate_vma_collect() is best effort, there is no need to revert and
   try to recollect from the beginning (to get that possible large
   folio or skip).

BTW, recollection will be more feasible if migrate_vma_collect() does
not do unmap singly-mapped optimization, since in the case, no PTE is
changed, we just need to reset migrate->->cpages and migrate->npages and
restart from the beginning.

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

Right. The PTE page table should be gone and the original PMD, pointing
to the PTE page table, becomes a leaf PMD or an invalid PMD, since
someone changed it when the PTE lock is dropped.

-- 
Best Regards,
Yan, Zi