Re: [PATCH v3 38/47] mm: fix deadlock of mremap() against UFFDIO_MOVE

[Lance Yang]

On Sat, Oct 31, 2026 at 10:40:07AM +0100, David Hildenbrand (Arm) wrote:
>From: Chris Mason <mason@xxxxxxxxxx>
>
>With per-VMA locks, UFFDIO_MOVE can run concurrently with mremap()
>on different VMAs in the same mm. Those VMAs can share page tables, so
>both operations can acquire the same pair of page-table locks.
>
>UFFDIO_MOVE orders the locks by address, while mremap() takes the source
>lock first. These conflicting orders can deadlock; mremap() holding
>mmap_lock for writing no longer helps.
>
>Move double_pt_lock() and double_pt_unlock() to mm/internal.h and use
>them for all page-table moves in mremap(). Preserve the source entry
>checks after acquiring both locks. Remove the comments claiming that
>exclusive mmap_lock makes lock ordering irrelevant.
>
>In move_ptes(), make sure to just recheck source and destination PMD
>after taking the locks and drop the overly-long comment.
>
>Fix generated by an LLM and sent by Chris Mason in private.
>
>[ david: use new helpers consistently; simplify description and comments;
>         move_ptes() fixup ]
>
>Fixes: 867a43a34ff8 ("userfaultfd: use per-vma locks in userfaultfd operations")
>Cc: stable@xxxxxxxxxxxxxxx
>Signed-off-by: Chris Mason <mason@xxxxxxxxxx>
>Reviewed-by: Lorenzo Stoakes (ARM) <ljs@xxxxxxxxxx>
>Acked-by: Muchun Song <muchun.song@xxxxxxxxx>
>Tested-by: Muhammad Usama Anjum <usama.anjum@xxxxxxx>
>Signed-off-by: David Hildenbrand (Arm) <david@xxxxxxxxxx>
>---

Nothing jumped out at me, so:

Reviewed-by: Lance Yang <lance.yang@xxxxxxxxx>