On Wed, Oct 21, 2026 at 10:36:01PM +0200, Konstantin Khorenko wrote: > This fixes no bug: it makes fork copy a PMD the way copy_present_ptes() > copies a PTE. Until now copy_huge_pmd() skipped every folio PMD of a > non-anonymous VMA and left the child to fault them in again, while the > PTEs of the same VMA are copied. > > Treat file folios as the PTE path does: take a reference, duplicate the > rmap and account them. fork then pays a reference and an rmap update > per PMD, and saves the child a fault per PMD it touches. The next patch > sends PFN mappings through the same tail. > > That covers the VMAs vma_needs_copy() sends here: > > - private file mappings with an anon_vma; > - VM_COPY_ON_FORK ones: uffd-wp and uffd-rwp, VM_MIXEDMAP (fuse DAX), > and VM_MAYBE_GUARD, which shared shmem, file and DAX mappings get > from a guard region. > > The DAX huge zero PMD is copied too, with a reference taken by > mm_get_huge_zero_folio() as for anonymous VMAs. A migration entry of a > file folio is copied and accounted like copy_nonpresent_pte() does, and > made read-only in both processes only in a CoW mapping. > > The copy then gets the same tail as __copy_present_ptes(): write > protect both sides in a CoW mapping, mark the child's copy clean in a > shared one, and drop the uffd-wp bit where the child is not armed. An > anonymous THP is now write protected only when its PMD is writable, as > a PTE is. > > A page table is deposited under the copy where the fault paths deposit > one: in anonymous VMAs, and wherever the architecture needs one. > > Suggested-by: David Hildenbrand <[email protected]> > Signed-off-by: Konstantin Khorenko <[email protected]>
Okay, I see benefit of aligning it to copy_present_ptes(). Reviewed-by: Kiryl Shutsemau (Meta) <[email protected]> -- Kiryl Shutsemau / Kirill A. Shutemov
