On 3/20/26 23:39, Lorenzo Stoakes (Oracle) wrote:
> Commit ac0a3fc9c07d ("mm: add ability to take further action in
> vm_area_desc") added the ability for drivers to instruct mm to take actions
> after the .mmap_prepare callback is complete.
>
> To make life simpler and safer, this is done before the VMA/mmap write lock
> is dropped but when the VMA is completely established.
>
> So on error, we simply munmap() the VMA.
>
> As part of this implementation, unfortunately a horrible hack had to be
> implemented to support some questionable behaviour hugetlb relies upon -
> that is that the file rmap lock is held until the operation is complete.
>
> The implementation, for convenience, did this in mmap_action_finish() so
> both the VMA and mmap_prepare compatibility layer paths would have this
> correctly handled.
>
> However, it turns out there is a mistake here - the rmap lock cannot be
> held on munmap, as free_pgtables() -> unlink_file_vma_batch_add() ->
> unlink_file_vma_batch_process() takes the file rmap lock.
>
> We therefore currently have a deadlock issue that might arise.
>
> Resolve this by leaving it to callers to handle the unmap.
>
> The compatibility layer does not support this rmap behaviour, so we simply
> have it unmap on error after calling mmap_action_complete().
>
> In the VMA implementation, we only perform the unmap after the rmap lock is
> dropped.
>
> This resolves the issue by ensuring the rmap lock is always dropped when
> the unmap occurs.
>
> Fixes: ac0a3fc9c07d ("mm: add ability to take further action in vm_area_desc")
> Cc: <[email protected]>
> Signed-off-by: Lorenzo Stoakes (Oracle) <[email protected]>
Acked-by: Vlastimil Babka (SUSE) <[email protected]>
