Re: [PATCH] mm/migrate_device: consolidate compound folio handling

[Hui Su]

Hi David,

> Two tab indent please.
>
> Just to be sure: there is no way we can currently validly trigger this, right?

Correct, as far as I can tell. I checked the current in-tree callers and do
not see a valid path that can trigger this condition.

The migrate_device_range() callers evict complete device-memory chunks,
and the migrate_device_pfns() caller expects large source folios to be
represented whole. In these cases, the supplied range or PFN array is
large enough to contain each encountered compound folio completely,
which is required because a compound folio cannot be partially migrated.

The condition is still reachable with invalid, truncated input. For
example, on a 4 KiB base-page system, passing only one entry for the head
of a 2 MiB device compound folio would leave one entry remaining while
folio_nr_pages() is 512. That would be caller misuse, and is the invariant
checked by the WARN_ON_ONCE().

I reran the original HMM migrate_anon_huge_zero reproducer on current
mainline. The private-device case passes, the coherent-device case is
skipped because DEVICE_COHERENT is unavailable in my test configuration,
and the test exits with status 0. I also instrumented the truncated
compound-folio condition; it was not hit, and no KASAN report was
observed.

I'll fix the helper parameter indentation and resend the patch.

Thanks,
Hui