linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Larry Woodman <lwoodman@redhat.com>
To: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: [PATCH] prevent deadlock in __unmap_hugepage_range() when alloc_huge_page() fails.
Date: Tue, 10 Nov 2009 12:00:56 -0500	[thread overview]
Message-ID: <1257872456.3227.2.camel@dhcp-100-19-198.bos.redhat.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 2959 bytes --]


hugetlb_fault() takes the mm->page_table_lock spinlock then calls
hugetlb_cow().  If the alloc_huge_page() in hugetlb_cow() fails due to
an insufficient huge page pool it calls unmap_ref_private() with the
mm->page_table_lock held.  unmap_ref_private() then calls
unmap_hugepage_range() which tries to acquire the mm->page_table_lock.


[<ffffffff810928c3>] print_circular_bug_tail+0x80/0x9f 
 [<ffffffff8109280b>] ? check_noncircular+0xb0/0xe8
 [<ffffffff810935e0>] __lock_acquire+0x956/0xc0e
 [<ffffffff81093986>] lock_acquire+0xee/0x12e
 [<ffffffff8111a7a6>] ? unmap_hugepage_range+0x3e/0x84
 [<ffffffff8111a7a6>] ? unmap_hugepage_range+0x3e/0x84
 [<ffffffff814c348d>] _spin_lock+0x40/0x89
 [<ffffffff8111a7a6>] ? unmap_hugepage_range+0x3e/0x84
 [<ffffffff8111afee>] ? alloc_huge_page+0x218/0x318
 [<ffffffff8111a7a6>] unmap_hugepage_range+0x3e/0x84
 [<ffffffff8111b2d0>] hugetlb_cow+0x1e2/0x3f4
 [<ffffffff8111b935>] ? hugetlb_fault+0x453/0x4f6
 [<ffffffff8111b962>] hugetlb_fault+0x480/0x4f6
 [<ffffffff8111baee>] follow_hugetlb_page+0x116/0x2d9
 [<ffffffff814c31a7>] ? _spin_unlock_irq+0x3a/0x5c
 [<ffffffff81107b4d>] __get_user_pages+0x2a3/0x427
 [<ffffffff81107d0f>] get_user_pages+0x3e/0x54
 [<ffffffff81040b8b>] get_user_pages_fast+0x170/0x1b5
 [<ffffffff81160352>] dio_get_page+0x64/0x14a
 [<ffffffff8116112a>] __blockdev_direct_IO+0x4b7/0xb31
 [<ffffffff8115ef91>] blkdev_direct_IO+0x58/0x6e
 [<ffffffff8115e0a4>] ? blkdev_get_blocks+0x0/0xb8
 [<ffffffff810ed2c5>] generic_file_aio_read+0xdd/0x528
 [<ffffffff81219da3>] ? avc_has_perm+0x66/0x8c
 [<ffffffff81132842>] do_sync_read+0xf5/0x146
 [<ffffffff8107da00>] ? autoremove_wake_function+0x0/0x5a
 [<ffffffff81211857>] ? security_file_permission+0x24/0x3a
 [<ffffffff81132fd8>] vfs_read+0xb5/0x126
 [<ffffffff81133f6b>] ? fget_light+0x5e/0xf8
 [<ffffffff81133131>] sys_read+0x54/0x8c
 [<ffffffff81011e42>] system_call_fastpath+0x16/0x1b

This can be fixed by dropping the mm->page_table_lock around the call 
to unmap_ref_private() if alloc_huge_page() fails, its dropped right below
in the normal path anyway:


diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 5d7601b..f4daef4 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1973,12 +1973,15 @@ retry_avoidcopy:
                 */
                if (outside_reserve) {
                        BUG_ON(huge_pte_none(pte));
+                       spin_unlock(&mm->page_table_lock);
                        if (unmap_ref_private(mm, vma, old_page, address)) {
+                               spin_lock(&mm->page_table_lock);
                                BUG_ON(page_count(old_page) != 1);
                                BUG_ON(huge_pte_none(pte));
                                goto retry_avoidcopy;
                        }
                        WARN_ON_ONCE(1);
+                       spin_lock(&mm->page_table_lock);
                }

                return -PTR_ERR(new_page);


Signed-off-by: Larry Woodman <lwooman@redhat.com>

[-- Attachment #2: hugetlb_cow.diff --]
[-- Type: text/x-patch, Size: 550 bytes --]

diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 5d7601b..f4daef4 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1973,12 +1973,15 @@ retry_avoidcopy:
 		 */
 		if (outside_reserve) {
 			BUG_ON(huge_pte_none(pte));
+			spin_unlock(&mm->page_table_lock);
 			if (unmap_ref_private(mm, vma, old_page, address)) {
+				spin_lock(&mm->page_table_lock);
 				BUG_ON(page_count(old_page) != 1);
 				BUG_ON(huge_pte_none(pte));
 				goto retry_avoidcopy;
 			}
 			WARN_ON_ONCE(1);
+			spin_lock(&mm->page_table_lock);
 		}
 
 		return -PTR_ERR(new_page);

             reply	other threads:[~2009-11-10 16:58 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-10 17:00 Larry Woodman [this message]
2009-11-16 20:12 ` Andrew Morton
2009-11-17 16:09   ` Mel Gorman
2009-11-17 16:43     ` Adam Litke
2009-11-18 16:27     ` Hugh Dickins
2009-11-19 14:22       ` Mel Gorman

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=1257872456.3227.2.camel@dhcp-100-19-198.bos.redhat.com \
    --to=lwoodman@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.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