linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: akpm@linux-foundation.org, aneesh.kumar@linux.vnet.ibm.com,
	dave@stgolabs.net, hughd@google.com, linux-mm@kvack.org,
	mhocko@kernel.org, mike.kravetz@oracle.com,
	mm-commits@vger.kernel.org, n-horiguchi@ah.jp.nec.com,
	stable@vger.kernel.org, torvalds@linux-foundation.org
Subject: [patch 02/16] mm/hugetlb: fix deadlock in hugetlb_cow error path
Date: Tue, 29 Dec 2020 15:14:25 -0800	[thread overview]
Message-ID: <20201229231425.rmDpurdQ4%akpm@linux-foundation.org> (raw)
In-Reply-To: <20201229151349.3285926ec0d1f65a27ac8534@linux-foundation.org>

From: Mike Kravetz <mike.kravetz@oracle.com>
Subject: mm/hugetlb: fix deadlock in hugetlb_cow error path

syzbot reported the deadlock here [1].  The issue is in hugetlb cow error
handling when there are not enough huge pages for the faulting task which
took the original reservation.  It is possible that other (child) tasks
could have consumed pages associated with the reservation.  In this case,
we want the task which took the original reservation to succeed.  So, we
unmap any associated pages in children so that they can be used by the
faulting task that owns the reservation.

The unmapping code needs to hold i_mmap_rwsem in write mode.  However, due
to commit c0d0381ade79 ("hugetlbfs: use i_mmap_rwsem for more pmd sharing
synchronization") we are already holding i_mmap_rwsem in read mode when
hugetlb_cow is called.  Technically, i_mmap_rwsem does not need to be held
in read mode for COW mappings as they can not share pmd's.  Modifying the
fault code to not take i_mmap_rwsem in read mode for COW (and other
non-sharable) mappings is too involved for a stable fix.  Instead, we
simply drop the hugetlb_fault_mutex and i_mmap_rwsem before unmapping. 
This is OK as it is technically not needed.  They are reacquired after
unmapping as expected by calling code.  Since this is done in an uncommon
error path, the overhead of dropping and reacquiring mutexes is
acceptable.

While making changes, remove redundant BUG_ON after unmap_ref_private.

[1] https://lkml.kernel.org/r/000000000000b73ccc05b5cf8558@google.com

Link: https://lkml.kernel.org/r/4c5781b8-3b00-761e-c0c7-c5edebb6ec1a@oracle.com
Fixes: c0d0381ade79 ("hugetlbfs: use i_mmap_rwsem for more pmd sharing synchronization")
Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com>
Reported-by: syzbot+5eee4145df3c15e96625@syzkaller.appspotmail.com
Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Hugh Dickins <hughd@google.com>
Cc: "Aneesh Kumar K . V" <aneesh.kumar@linux.vnet.ibm.com>
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 mm/hugetlb.c |   22 +++++++++++++++++++++-
 1 file changed, 21 insertions(+), 1 deletion(-)

--- a/mm/hugetlb.c~mm-hugetlb-fix-deadlock-in-hugetlb_cow-error-path
+++ a/mm/hugetlb.c
@@ -4105,10 +4105,30 @@ retry_avoidcopy:
 		 * may get SIGKILLed if it later faults.
 		 */
 		if (outside_reserve) {
+			struct address_space *mapping = vma->vm_file->f_mapping;
+			pgoff_t idx;
+			u32 hash;
+
 			put_page(old_page);
 			BUG_ON(huge_pte_none(pte));
+			/*
+			 * Drop hugetlb_fault_mutex and i_mmap_rwsem before
+			 * unmapping.  unmapping needs to hold i_mmap_rwsem
+			 * in write mode.  Dropping i_mmap_rwsem in read mode
+			 * here is OK as COW mappings do not interact with
+			 * PMD sharing.
+			 *
+			 * Reacquire both after unmap operation.
+			 */
+			idx = vma_hugecache_offset(h, vma, haddr);
+			hash = hugetlb_fault_mutex_hash(mapping, idx);
+			mutex_unlock(&hugetlb_fault_mutex_table[hash]);
+			i_mmap_unlock_read(mapping);
+
 			unmap_ref_private(mm, vma, old_page, haddr);
-			BUG_ON(huge_pte_none(pte));
+
+			i_mmap_lock_read(mapping);
+			mutex_lock(&hugetlb_fault_mutex_table[hash]);
 			spin_lock(ptl);
 			ptep = huge_pte_offset(mm, haddr, huge_page_size(h));
 			if (likely(ptep &&
_


  parent reply	other threads:[~2020-12-29 23:14 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-29 23:13 incoming Andrew Morton
2020-12-29 23:14 ` [patch 01/16] selftests/vm: fix building protection keys test Andrew Morton
2020-12-29 23:14 ` Andrew Morton [this message]
2020-12-29 23:14 ` [patch 03/16] Revert "kbuild: avoid static_assert for genksyms" Andrew Morton
2020-12-29 23:14 ` [patch 04/16] checkpatch: prefer strscpy to strlcpy Andrew Morton
2020-12-29 23:14 ` [patch 05/16] mm: add prototype for __add_to_page_cache_locked() Andrew Morton
2020-12-29 23:14 ` [patch 06/16] mm: memmap defer init doesn't work as expected Andrew Morton
2020-12-29 23:14 ` [patch 07/16] mm/mremap.c: fix extent calculation Andrew Morton
2020-12-29 23:14 ` [patch 08/16] mm: generalise COW SMC TLB flushing race comment Andrew Morton
2020-12-29 23:14 ` [patch 09/16] kasan: fix null pointer dereference in kasan_record_aux_stack Andrew Morton
2020-12-29 23:14 ` [patch 10/16] local64.h: make <asm/local64.h> mandatory Andrew Morton
2020-12-29 23:14 ` [patch 11/16] sizes.h: add SZ_8G/SZ_16G/SZ_32G macros Andrew Morton
2020-12-29 23:14 ` [patch 12/16] kdev_t: always inline major/minor helper functions Andrew Morton
2020-12-29 23:14 ` [patch 13/16] lib/genalloc: fix the overflow when size is too big Andrew Morton
2020-12-29 23:15 ` [patch 14/16] lib/zlib: fix inflating zlib streams on s390 Andrew Morton
2020-12-29 23:15 ` [patch 15/16] zlib: move EXPORT_SYMBOL() and MODULE_LICENSE() out of dfltcc_syms.c Andrew Morton
2020-12-29 23:15 ` [patch 16/16] mm: slub: call account_slab_page() after slab page initialization Andrew Morton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201229231425.rmDpurdQ4%akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=aneesh.kumar@linux.vnet.ibm.com \
    --cc=dave@stgolabs.net \
    --cc=hughd@google.com \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=mike.kravetz@oracle.com \
    --cc=mm-commits@vger.kernel.org \
    --cc=n-horiguchi@ah.jp.nec.com \
    --cc=stable@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).