Re: [PATCH 08/12] mm/migrate_device: do not migrate a uffd-protected zero page

["Gregory Price (Meta)" <gourry@gourry.net>]

On 2026-11-11 12:55 -0500, Tal Zussman wrote:
> migrate_vma_setup() installs a migration entry for each page it
> collects, which carries the uffd bit over to the new PTE. However, a PTE
> that maps the zero page is left in place without a migration entry.
> migrate_vma_insert_page() later overwrites it with a new PTE that is
> built only from the VMA flags, so the uffd-wp bit or the RWP PAGE_NONE
> protection of the old PTE is lost. The same applies to the huge zero
> PMD.
> 
> Once a driver has migrated such a zero page, writes and accesses to it
> no longer fault into userfaultfd, so the manager misses them. With async
> tracking, PAGEMAP_SCAN unconditionally reports the page as written or
> accessed.
> 
> This requires a driver that migrates memory to a device.
> 
> To fix it, do not mark a zero page for migration if its entry has the
> uffd bit set in a VMA registered for WP or RWP. The driver sees an
> address that was not migrated, which drivers already have to deal with.
> 
> The uffd bit can also be set after the zero page was collected, as
> write-protecting only takes the mmap lock for read. So check again under
> the page table lock in migrate_vma_insert_page() and
> migrate_vma_insert_huge_pmd_page().
> 

Similar to last patch, this changelog could be improved.  My best
attempt at summarizing:

"""
Device migration replaces a zero-page mapping with a fresh entry,
losing its userfaultfd WP or RWP protection.

Don't migrate the uffd-protected zero pages.

Skip protected zero pages during collection. Check again under the
page-table lock before insertion, because another thread can apply
protection after collection finishes.

The alternative ...
"""

I have concerns with this:

> The alternative would be to carry the uffd state over in
> migrate_vma_insert_page() and migrate_vma_insert_huge_pmd_page(). Not
> migrating the zero page is simpler, and a zero page that is protected by
> userfaultfd in a range that a driver migrates should be rare.

This basically force-fails a migration of a uffd protected zero page.

Wouldn't we expect this to cause drivers to fail to make progress if
they require that page to be resident on the device?  Not sure we want
to force drivers to try to handle this special case (if they even can).

We'll need some input from the migrate_device/GPU folks.

-- 
~Gregory