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

["Lorenzo Stoakes (ARM)" <ljs@kernel.org>]

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.

> These all are handled in the HMM walk based migration series.

Ack great glad to hear :)

--
Cheers, Lorenzo