Re: [PATCH] mm/migrate: fix hugetlbfs deadlock by respecting lock ordering

[Jinchao Wang]

On Fri, Jan 09, 2026 at 02:37:28PM +0800, Huang, Ying wrote:
> Jinchao Wang <wangjinchao600@xxxxxxxxx> writes:
> 
> > Fix an AB-BA deadlock between hugetlbfs_punch_hole() and page migration.
> >
> > The deadlock occurs because migration violates the lock ordering defined
> > in mm/rmap.c for hugetlbfs:
> >
> >   * hugetlbfs PageHuge() take locks in this order:
> >   * hugetlb_fault_mutex
> >   * vma_lock
> >   * mapping->i_mmap_rwsem
> >   * folio_lock
> >
> > The following trace illustrates the inversion:
> >
> > Task A (punch_hole):             Task B (migration):
> > --------------------             -------------------
> > 1. i_mmap_lock_write(mapping)    1. folio_lock(folio)
> > 2. folio_lock(folio)             2. i_mmap_lock_read(mapping)
> >    (blocks waiting for B)           (blocks waiting for A)
> >
> > Task A is blocked in the punch-hole path:
> >   hugetlbfs_fallocate
> >     hugetlbfs_punch_hole
> >       hugetlbfs_zero_partial_page
> >         folio_lock
> >
> > Task B is blocked in the migration path:
> >   migrate_pages
> >     unmap_and_move_huge_page
> >       remove_migration_ptes
> >         __rmap_walk_file
> >           i_mmap_lock_read
> >
> > To fix this, adjust unmap_and_move_huge_page() to respect the established
> > hierarchy. If i_mmap_rwsem is acquired during try_to_migrate(), hold it
> > until remove_migration_ptes() completes.
> >
> > This utilizes the existing retry logic, which unlocks the folio and
> > returns -EAGAIN if hugetlb_folio_mapping_lock_write() fails.
> >
> > Link: https://lore.kernel.org/all/68e9715a.050a0220.1186a4.000d.GAE@xxxxxxxxxx/
> > Link: https://lore.kernel.org/all/20260108123957.1123502-2-wangjinchao600@xxxxxxxxx
> > Reported-by: syzbot+2d9c96466c978346b55f@xxxxxxxxxxxxxxxxxxxxxxxxx
> > Suggested-by: Matthew Wilcox <willy@xxxxxxxxxxxxx>
> > Signed-off-by: Jinchao Wang <wangjinchao600@xxxxxxxxx>
> 
> Can you provide a "Fixes:" tag?  That is helpful for backporting the bug
> fix.

Thanks for the suggestion. 
The deadlock appears to be caused by a violation of the lock ordering 
introduced in commit 336bf30eb765 ("hugetlbfs: fix anon huge page migration 
race"). Although commit 68d32527d340 ("hugetlbfs: zero partial pages during 
fallocate hole punch") was the one that first triggered the crash, 
I believe the 336bf30eb765 commit is the root cause.

I will add the following tag to v2:
Fixes: 336bf30eb765 ("hugetlbfs: fix anon huge page migration race")
> 
> ---
> Best Regards,
> Huang, Ying