Re: [PATCH 05/10] mm/hugetlb: don't clear the resv_map of a VMA whose lock is held

[Lance Yang]

On Thu, Oct 15, 2026 at 06:07:11PM +0200, David Hildenbrand (Arm) wrote:
>From: Josef Bacik <josef@xxxxxxxxxxxxxx>
>
>Since commit bf4916922c60 ("hugetlbfs: extend hugetlb_vma_lock to private
>VMAs") the lock of a private hugetlb VMA that owns a reservation is the
>rw_sema of its resv_map.  The hugetlb_vma_*lock*() helpers find it through
>vma->vm_private_data, anew for every lock and every unlock.
>
>At the end of mremap() the old VMA has to let go of the resv_map, which
>now belongs to the new VMA: clear_vma_resv_huge_pages() stores NULL into
>vm_private_data.  mremap() holds mmap_lock for writing and has write
>locked the VMA, which keeps away everybody who comes through the mm.  It
>does not keep away those who find the VMA through the file.  For hole
>punch and truncation hugetlb_vmdelete_list() does
>
>	hugetlb_vma_trylock_write(vma);		locks resv_map->rw_sema
>	unmap_hugepage_range(vma, ...);
>						vm_private_data = NULL
>	hugetlb_vma_unlock_write(vma);		no resv_map: does nothing
>
>and the rw_sema stays write locked for ever:
>
>  WARNING: lock held when returning to user space!
>  mremap_punch/116 is leaving the kernel with locks still held!
>  locks held by mremap_punch/116: 1, last CPU#1:
>   #0: (&resv_map->rw_sema){+.+.}-{4:4}, at:
>                                       hugetlb_vmdelete_list+0x46/0x160
>
>The next fault in the new VMA sleeps in hugetlb_vma_lock_read(),
>uninterruptibly, and it holds its entry of hugetlb_fault_mutex_table[].
>That table is global, so a fault of any other process on a page that
>hashes to the same entry sleeps uninterruptibly as well.
>
>All those who take the lock of a private VMA without taking the mmap/vma
>lock are affected: rmap walks. So hold i_mmap_rwsem around the clearing
>of the resv_map.
>
>No change of behaviour, other than that mremap() of a hugetlb VMA takes
>i_mmap_rwsem once more.
>
>Original fix generated by an LLM and sent in private by Josef.
>
>Fixes: bf4916922c60 ("hugetlbfs: extend hugetlb_vma_lock to private VMAs")
>Reported-by: Chris Mason <mason@xxxxxxxxxx>
>Cc: stable@xxxxxxxxxxxxxxx
>Signed-off-by: Josef Bacik <josef@xxxxxxxxxxxxxx>
>Reviewed-by: Lorenzo Stoakes (ARM) <ljs@xxxxxxxxxx>
>[ david: avoid local variable, move and refine comment, description cleanups+simplifications ]
>Signed-off-by: David Hildenbrand (Arm) <david@xxxxxxxxxx>
>---

Nothing jumped out at me, so:

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