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

["David Hildenbrand (Arm)" <david@kernel.org>]

On 7/10/26 17:35, Zi Yan wrote:
> On Fri Jul 10, 2026 at 7:56 AM EDT, David Hildenbrand (Arm) wrote:
>> On 7/10/26 13:30, Zi Yan wrote:
>>>
>>> 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;

Yes.

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

Yes.

> 
> 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).

Yes.

> 
> 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.

Right, so I guess we'd have to remember how far to rollback, and rollback would
mean resetting migrate->->cpages and migrate->npages.

And for the entries we rollback, we have to decide whether to folio_put() and
whether to folio_unlock() [fault_folio != folio]. That's the confusing bit given
that the code is rather "interesting".

-- 
Cheers,

David