From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 64FC72D5925; Tue, 31 Mar 2026 00:43:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774917786; cv=none; b=ULls+RkuhdJV+kvD0WnSsO0oO1B2YkwgKs1Lvrqpufpzq6IN7JKS8zg+rTce5jBHKbeZKi0NTIqwMM8EzyeoOa5htAw3r/KdeAzFvlXeWSAmiE3xtPTe84C4WicYRqP73eNwFAMIAicQGl8HAE0/PN8BU8pXFaGEI55PKKaCBHk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774917786; c=relaxed/simple; bh=gErGqUvUYoA4k7TkXNuYAgpt2UiwKXKyxDCeRe6IygU=; h=Date:To:From:Subject:Message-Id; b=El9mIVIc3t/6P/d94j7xmXt1wsh1p+5QKAgXjY12oMXGmy3FIEoALtbvd4cu3HbD1Hmu5LJF/FgaKA+kgPiiA5A/Bzqxl6xAr/DxHJvO+CELUuAa+IhG7UjIWS1YOl8O76uAZpNQfApL6RSFET2ReJp6fzdemx7OYuOOfO9KqHU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=ag9YKuGW; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="ag9YKuGW" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 37961C4CEF7; Tue, 31 Mar 2026 00:43:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1774917786; bh=gErGqUvUYoA4k7TkXNuYAgpt2UiwKXKyxDCeRe6IygU=; h=Date:To:From:Subject:From; b=ag9YKuGWKwYdYccPmw4p3Hr0KMUFBXTPN+EUYw3A7nRKobJRVhrHh1gzhJjGNHxAa +Z/42uW0UVDHbFGx9prl/vpTS3mOqNbFVnNn6iaN0RW6wSkvgmDw9fSFsjc5rAE6JV IkrHZ4LDjEl2oO3jRhwt/FfvCNg+9HFg7RTvw82Y= Date: Mon, 30 Mar 2026 17:43:05 -0700 To: mm-commits@vger.kernel.org,wei.liu@kernel.org,viro@zeniv.linux.org.uk,vigneshr@ti.com,vbabka@kernel.org,surenb@google.com,stable@vger.kernel.org,ryan.roberts@arm.com,rppt@kernel.org,richard@nod.at,pfalcato@suse.de,miquel.raynal@bootlin.com,mhocko@suse.com,mcoquelin.stm32@gmail.com,martin.petersen@oracle.com,marc.dionne@auristor.com,longli@microsoft.com,liam.howlett@oracle.com,kys@microsoft.com,jannh@google.com,jack@suse.cz,haiyangz@microsoft.com,gregkh@linuxfoundation.org,dhowells@redhat.com,decui@microsoft.com,david@kernel.org,corbet@lwn.net,clemens@ladisch.de,brauner@kernel.org,bostroesser@gmail.com,arnd@arndb.de,alexandre.torgue@foss.st.com,alexander.shishkin@linux.intel.com,ljs@kernel.org,akpm@linux-foundation.org From: Andrew Morton Subject: [merged mm-stable] mm-avoid-deadlock-when-holding-rmap-on-mmap_prepare-error.patch removed from -mm tree Message-Id: <20260331004306.37961C4CEF7@smtp.kernel.org> Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: The quilt patch titled Subject: mm: avoid deadlock when holding rmap on mmap_prepare error has been removed from the -mm tree. Its filename was mm-avoid-deadlock-when-holding-rmap-on-mmap_prepare-error.patch This patch was dropped because it was merged into the mm-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: "Lorenzo Stoakes (Oracle)" Subject: mm: avoid deadlock when holding rmap on mmap_prepare error Date: Fri, 20 Mar 2026 22:39:30 +0000 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. Link: https://lkml.kernel.org/r/d44248be9da68258b07c2c59d4e73485ee0ca943.1774045440.git.ljs@kernel.org Fixes: ac0a3fc9c07d ("mm: add ability to take further action in vm_area_desc") Signed-off-by: Lorenzo Stoakes (Oracle) Acked-by: Vlastimil Babka (SUSE) Cc: Alexander Shishkin Cc: Alexandre Torgue Cc: Al Viro Cc: Arnd Bergmann Cc: Bodo Stroesser Cc: Christian Brauner Cc: Clemens Ladisch Cc: David Hildenbrand Cc: David Howells Cc: Dexuan Cui Cc: Greg Kroah-Hartman Cc: Haiyang Zhang Cc: Jan Kara Cc: Jann Horn Cc: Jonathan Corbet Cc: K. Y. Srinivasan Cc: Liam Howlett Cc: Long Li Cc: Marc Dionne Cc: "Martin K. Petersen" Cc: Maxime Coquelin Cc: Michal Hocko Cc: Mike Rapoport Cc: Miquel Raynal Cc: Pedro Falcato Cc: Richard Weinberger Cc: Ryan Roberts Cc: Suren Baghdasaryan Cc: Vignesh Raghavendra Cc: Vlastimil Babka (SUSE) Cc: Wei Liu Cc: Signed-off-by: Andrew Morton --- mm/util.c | 12 +++++++----- mm/vma.c | 13 ++++++++++--- 2 files changed, 17 insertions(+), 8 deletions(-) --- a/mm/util.c~mm-avoid-deadlock-when-holding-rmap-on-mmap_prepare-error +++ a/mm/util.c @@ -1215,7 +1215,13 @@ int compat_vma_mmap(struct file *file, s return err; set_vma_from_desc(vma, &desc); - return mmap_action_complete(vma, &desc.action); + err = mmap_action_complete(vma, &desc.action); + if (err) { + const size_t len = vma_pages(vma) << PAGE_SHIFT; + + do_munmap(current->mm, vma->vm_start, len, NULL); + } + return err; } EXPORT_SYMBOL(compat_vma_mmap); @@ -1316,10 +1322,6 @@ static int mmap_action_finish(struct vm_ * invoked if we do NOT merge, so we only clean up the VMA we created. */ if (err) { - const size_t len = vma_pages(vma) << PAGE_SHIFT; - - do_munmap(current->mm, vma->vm_start, len, NULL); - if (action->error_hook) { /* We may want to filter the error. */ err = action->error_hook(err); --- a/mm/vma.c~mm-avoid-deadlock-when-holding-rmap-on-mmap_prepare-error +++ a/mm/vma.c @@ -2735,9 +2735,9 @@ static int call_action_complete(struct m struct mmap_action *action, struct vm_area_struct *vma) { - int ret; + int err; - ret = mmap_action_complete(vma, action); + err = mmap_action_complete(vma, action); /* If we held the file rmap we need to release it. */ if (map->hold_file_rmap_lock) { @@ -2745,7 +2745,14 @@ static int call_action_complete(struct m i_mmap_unlock_write(file->f_mapping); } - return ret; + + if (err) { + const size_t len = vma_pages(vma) << PAGE_SHIFT; + + do_munmap(current->mm, vma->vm_start, len, NULL); + } + + return err; } static unsigned long __mmap_region(struct file *file, unsigned long addr, _ Patches currently in -mm which might be from ljs@kernel.org are maintainers-update-mglru-entry-to-reflect-current-status.patch selftests-mm-add-merge-test-for-partial-msealed-range.patch