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

[Muchun Song]

> On Oct 16, 2026, at 00:07, David Hildenbrand (Arm) <david@xxxxxxxxxx> 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>

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

Thanks.