From: Johannes Weiner <hannes@cmpxchg.org>
To: Yinghai Lu <yinghai@kernel.org>
Cc: akpm@linux-foundation.org, mm-commits@vger.kernel.org,
	tj@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: [patch 1/2] mm: sparse: fix section usemap placement calculation
Date: Wed, 11 Jul 2012 00:17:50 +0200	[thread overview]
Message-ID: <20120710221750.GI1779@cmpxchg.org> (raw)
In-Reply-To: <20120710221559.GH1779@cmpxchg.org>
From: Yinghai Lu <yinghai@kernel.org>
238305b "mm: remove sparsemem allocation details from the bootmem
allocator" introduced a bug in the allocation goal calculation that
put section usemaps not in the same section as the node descriptors,
creating unnecessary hotplug dependencies between them:
[    0.000000] node 0 must be removed before remove section 16399
[    0.000000] node 1 must be removed before remove section 16399
[    0.000000] node 2 must be removed before remove section 16399
[    0.000000] node 3 must be removed before remove section 16399
[    0.000000] node 4 must be removed before remove section 16399
[    0.000000] node 5 must be removed before remove section 16399
[    0.000000] node 6 must be removed before remove section 16399
The reason is that it applies PAGE_SECTION_MASK to the physical
address of the node descriptor when finding a suitable place to put
the usemap, when this mask is actually intended to be used with PFNs.
Because the PFN mask is wider, the target address will point beyond
the wanted section holding the node descriptor and the node must be
offlined before the section holding the usemap can go.
Fix this by extending the mask to address width before use.
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
---
 mm/sparse.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/mm/sparse.c b/mm/sparse.c
index 6a4bf91..e861397 100644
--- a/mm/sparse.c
+++ b/mm/sparse.c
@@ -287,7 +287,7 @@ sparse_early_usemaps_alloc_pgdat_section(struct pglist_data *pgdat,
 	 * from the same section as the pgdat where possible to avoid
 	 * this problem.
 	 */
-	goal = __pa(pgdat) & PAGE_SECTION_MASK;
+	goal = __pa(pgdat) & (PAGE_SECTION_MASK << PAGE_SHIFT);
 	host_pgdat = NODE_DATA(early_pfn_to_nid(goal >> PAGE_SHIFT));
 	return __alloc_bootmem_node_nopanic(host_pgdat, size,
 					    SMP_CACHE_BYTES, goal);
-- 
1.7.7.6
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next      parent reply	other threads:[~2012-07-10 22:18 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20120626234630.A54C9A0341@akpm.mtv.corp.google.com>
     [not found] ` <CAE9FiQUeQG6nr_k54ixEA4pvRT00e4bWoMJ+m0NO=FPEnBDB8Q@mail.gmail.com>
     [not found]   ` <CAE9FiQX_ovuiGHShf72kLOe4WJybZiyWiGaQ9KUnc1jm3cvdHw@mail.gmail.com>
     [not found]     ` <20120710212005.GG1779@cmpxchg.org>
     [not found]       ` <20120710221559.GH1779@cmpxchg.org>
2012-07-10 22:17         ` Johannes Weiner [this message]
2012-07-10 22:18         ` [patch 2/2] mm: sparse: fix usemap allocation above node descriptor section Johannes Weiner
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=20120710221750.GI1779@cmpxchg.org \
    --to=hannes@cmpxchg.org \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mm-commits@vger.kernel.org \
    --cc=tj@kernel.org \
    --cc=yinghai@kernel.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).