From: David Gibson <david@gibson.dropbear.id.au>
To: Andrew Morton <akpm@osdl.org>
Cc: linux-kernel@vger.kernel.org, Andy Whitworth <apw@shadowen.org>,
Adam Litke <agl@us.ibm.com>,
linuxppc64-dev@lists.linuxppc.org
Subject: Minor hugepage bugfix
Date: Fri, 7 May 2004 16:07:06 +1000 [thread overview]
Message-ID: <20040507060706.GE16901@zax> (raw)
Andrew, please apply:
add_to_page_cache() locks the given page if and only if it suceeds.
The hugepage code (every arch), however, does an unlock_page() after
add_to_page_cache() before checking the return code, which could trip
the BUG() in unlock_page() if add_to_page_cache() failed.
In practice we've never hit this bug, because the only ways
add_to_page_cache() can fail are when we fail to allocate a radix tree
node (very rare), or when there is already a page at that offset in
the radix tree, which never happens during prefault, obviously. We
should probably fix it anyway, though.
The analagous bug in some of the patches floating about to
demand-allocation of hugepages is more of a problem, because multiple
processes can race to instantiate a particular page in the radix tree
- that's been hit at least once (which is how I found this).
Index: working-2.6/arch/ppc64/mm/hugetlbpage.c
===================================================================
--- working-2.6.orig/arch/ppc64/mm/hugetlbpage.c 2004-05-05 10:05:52.000000000 +1000
+++ working-2.6/arch/ppc64/mm/hugetlbpage.c 2004-05-07 15:52:28.536883064 +1000
@@ -452,8 +452,9 @@
goto out;
}
ret = add_to_page_cache(page, mapping, idx, GFP_ATOMIC);
- unlock_page(page);
- if (ret) {
+ if (! ret) {
+ unlock_page(page);
+ } else {
hugetlb_put_quota(mapping);
free_huge_page(page);
goto out;
Index: working-2.6/arch/i386/mm/hugetlbpage.c
===================================================================
--- working-2.6.orig/arch/i386/mm/hugetlbpage.c 2004-04-28 09:37:18.000000000 +1000
+++ working-2.6/arch/i386/mm/hugetlbpage.c 2004-05-07 15:52:28.537882912 +1000
@@ -264,8 +264,9 @@
goto out;
}
ret = add_to_page_cache(page, mapping, idx, GFP_ATOMIC);
- unlock_page(page);
- if (ret) {
+ if (! ret) {
+ unlock_page(page);
+ } else {
hugetlb_put_quota(mapping);
free_huge_page(page);
goto out;
Index: working-2.6/arch/ia64/mm/hugetlbpage.c
===================================================================
--- working-2.6.orig/arch/ia64/mm/hugetlbpage.c 2004-04-28 09:37:18.000000000 +1000
+++ working-2.6/arch/ia64/mm/hugetlbpage.c 2004-05-07 15:53:19.858935352 +1000
@@ -293,8 +293,9 @@
goto out;
}
ret = add_to_page_cache(page, mapping, idx, GFP_ATOMIC);
- unlock_page(page);
- if (ret) {
+ if (! ret) {
+ unlock_page(page);
+ } else {
hugetlb_put_quota(mapping);
free_huge_page(page);
goto out;
Index: working-2.6/arch/sparc64/mm/hugetlbpage.c
===================================================================
--- working-2.6.orig/arch/sparc64/mm/hugetlbpage.c 2004-04-28 09:37:19.000000000 +1000
+++ working-2.6/arch/sparc64/mm/hugetlbpage.c 2004-05-07 15:53:54.482863760 +1000
@@ -244,8 +244,9 @@
goto out;
}
ret = add_to_page_cache(page, mapping, idx, GFP_ATOMIC);
- unlock_page(page);
- if (ret) {
+ if (! ret) {
+ unlock_page(page);
+ } else {
hugetlb_put_quota(mapping);
free_huge_page(page);
goto out;
Index: working-2.6/arch/sh/mm/hugetlbpage.c
===================================================================
--- working-2.6.orig/arch/sh/mm/hugetlbpage.c 2004-04-28 09:37:19.000000000 +1000
+++ working-2.6/arch/sh/mm/hugetlbpage.c 2004-05-07 15:54:19.282954200 +1000
@@ -248,8 +248,9 @@
goto out;
}
ret = add_to_page_cache(page, mapping, idx, GFP_ATOMIC);
- unlock_page(page);
- if (ret) {
+ if (! ret) {
+ unlock_page(page);
+ } else {
hugetlb_put_quota(mapping);
free_huge_page(page);
goto out;
--
David Gibson | For every complex problem there is a
david AT gibson.dropbear.id.au | solution which is simple, neat and
| wrong.
http://www.ozlabs.org/people/dgibson
reply other threads:[~2004-05-07 6:11 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20040507060706.GE16901@zax \
--to=david@gibson.dropbear.id.au \
--cc=agl@us.ibm.com \
--cc=akpm@osdl.org \
--cc=apw@shadowen.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc64-dev@lists.linuxppc.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