Re: [PATCH v2 05/13] mm/migrate_device: don't collect a range twice

["Mika Penttilä" <mpenttil@redhat.com>]

On 11/14/26 20:34, Lorenzo Stoakes (ARM) wrote:
> On Sat, Nov 14, 2026 at 08:45:55AM +0200, Mika Penttilä wrote:
>> On 11/14/26 07:09, Balbir Singh wrote:
>>>> diff --git a/mm/migrate_device.c b/mm/migrate_device.c
>>>> index 9e5dab8e1b77..28ed706109da 100644
>>>> --- a/mm/migrate_device.c
>>>> +++ b/mm/migrate_device.c
>>>> @@ -257,13 +257,17 @@ static int migrate_vma_collect_pmd(pmd_t *pmdp,
>>>>  	pte_t *ptep;
>>>>
>>>>  again:
>>>> +	/* [start, addr) is collected if we get here after splitting a folio */
>>>>  	if (pmd_trans_huge(*pmdp) || !pmd_present(*pmdp)) {
>>>> -		int ret = migrate_vma_collect_huge_pmd(pmdp, start, end, walk, fault_folio);
>>>> +		int ret = migrate_vma_collect_huge_pmd(pmdp, addr, end, walk, fault_folio);
>>>>
>>>>  		if (ret == -EAGAIN)
>>>>  			goto again;
>>>> -		if (ret == 0)
>>>> +		if (ret == 0) {
>>>> +			if (unmapped)
>>>> +				flush_tlb_range(walk->vma, start, end);
>>>>  			return 0;
>>>> +		}
>>>>  	}
>>>>
>>>>  	ptep = pte_offset_map_lock(mm, pmdp, start, &ptl);
>>>>
>>> Is the intended race a concurrent MADV_DONTNEED reclaiming the PTE table while
>>> PTL is dropped for the split? That would leave pmd_none() true on retry, entering
>>> migrate_vma_collect_huge_pmd() through !pmd_present() and taking its hole path.
> Balbir - yeah exactly the PTE page table removal, and it zaps the migration
> entries installed for [start, adr) too, so those don't keep the table alive.
>
> And yeah, we would then see pmd_none() on retry and
> migrate_vma_collect_hole(start, end, ...) would appends entries on top of those
> already collected.
>
>> I think this is "ok" for the fix, the hole is collected from [addr, end).
> Thanks. Yeah addr > start, so it's not PMD-aligned so always ends up in the
> per-page path.
>
> And if the split happened at the first entry then nothing is collected yet
> anwyay.
>
>> But couple of things follow. It can't be possibly collected as
>> MIGRATE_PFN_COMPOUND entry, only small pages. And the collected entries
>> in [start, addr) are wrong ones.  Finalize will recover, but the
>> migration will fail for those.
> But that's true for any zap that races after collection started, so there's
> nothing for this fix to do here.
Yeah agree this fix is fine and good for stable. To collect the whole
PMD hole a rollback mechanism is needed.
>> These all are handled in the HMM walk based migration series.
> Ack great glad to hear :)
>
> --
> Cheers, Lorenzo

--Mika