Re: [PATCH 37/46] mm: fix deadlock of mremap() against UFFDIO_MOVE

[Muchun Song]

> On Oct 27, 2026, at 07:17, David Hildenbrand (Arm) <david@xxxxxxxxxx> 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.
> 
> Fixes: 867a43a34ff8 ("userfaultfd: use per-vma locks in userfaultfd operations")
> Cc: stable@xxxxxxxxxxxxxxx
> Signed-off-by: Chris Mason <mason@xxxxxxxxxx>
> [ david: use new helpers consistently; simplify description and comments;
>         move_ptes() fixup ]
> Signed-off-by: David Hildenbrand (Arm) <david@xxxxxxxxxx>

Acked-by: Muchun Song <muchun.song@xxxxxxxxx>

Thanks.