public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Denys Fedoryshchenko <denys@visp.net.lb>
Cc: linux-kernel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	"H. Peter Anvin" <hpa@zytor.com>, Mel Gorman <mel@csn.ul.ie>
Subject: Re: bugreport kernel panic on early stage, with HIGHMEM4G:
Date: Tue, 15 Jan 2008 14:13:40 +0100	[thread overview]
Message-ID: <20080115131340.GA6237@elte.hu> (raw)
In-Reply-To: <20080115113947.GA14603@elte.hu>


* Ingo Molnar <mingo@elte.hu> wrote:

> thanks for the detailed report, i think i know what's going on. Could 
> you try the patch below, does it fix your problem?

find below the fix with a more complete changelog and with no debugging 
printouts.

	Ingo

-------------->
Subject: x86: fix boot crash on HIGHMEM4G && SPARSEMEM
From: Ingo Molnar <mingo@elte.hu>

Denys Fedoryshchenko reported a bootup crash when he upgraded
his system from 3GB to 4GB RAM:

   http://lkml.org/lkml/2008/1/7/9

the bug is due to HIGHMEM4G && SPARSEMEM kernels making pfn_to_page() to 
return an invalid pointer when the pfn is in a memory hole. The 256 MB 
PCI aperture at the end of RAM was not mapped by sparsemem, and hence 
the pfn was not valid. But set_highmem_pages_init() iterated this range 
without checking the pfn's validity first - crashing the bootup.

this bug was probably present in the sparsemem code ever since sparsemem 
has been introduced in v2.6.13. It was masked due to HIGHMEM64G using 
larger memory regions in sparsemem_32.h:

 #ifdef CONFIG_X86_PAE
 #define SECTION_SIZE_BITS       30
 #define MAX_PHYSADDR_BITS       36
 #define MAX_PHYSMEM_BITS        36
 #else
 #define SECTION_SIZE_BITS       26
 #define MAX_PHYSADDR_BITS       32
 #define MAX_PHYSMEM_BITS        32
 #endif

which creates 1GB sparsemem regions instead of 64MB sparsemem regions. 
So in practice we only ever created true sparsemem holes on x86 with 
HIGHMEM4G - but that was rarely used by distros.

( btw., we could probably save 2MB of mem_map[]s on X86_PAE if we reduced
  the sparsemem region size to 256 MB. )

Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
 arch/x86/mm/init_32.c |    9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

Index: linux/arch/x86/mm/init_32.c
===================================================================
--- linux.orig/arch/x86/mm/init_32.c
+++ linux/arch/x86/mm/init_32.c
@@ -321,8 +321,13 @@ extern void set_highmem_pages_init(int);
 static void __init set_highmem_pages_init(int bad_ppro)
 {
 	int pfn;
-	for (pfn = highstart_pfn; pfn < highend_pfn; pfn++)
-		add_one_highpage_init(pfn_to_page(pfn), pfn, bad_ppro);
+	for (pfn = highstart_pfn; pfn < highend_pfn; pfn++) {
+		/*
+		 * Holes under sparsemem might not have no mem_map[]:
+		 */
+		if (pfn_valid(pfn))
+			add_one_highpage_init(pfn_to_page(pfn), pfn, bad_ppro);
+	}
 	totalram_pages += totalhigh_pages;
 }
 #endif /* CONFIG_FLATMEM */

  reply	other threads:[~2008-01-15 13:14 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-07  5:47 bugreport kernel panic on early stage, with HIGHMEM4G: Denys Fedoryshchenko
2008-01-15 11:39 ` Ingo Molnar
2008-01-15 13:13   ` Ingo Molnar [this message]
2008-01-17 12:26     ` Mel Gorman
2008-01-17 13:31   ` Denys Fedoryshchenko

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=20080115131340.GA6237@elte.hu \
    --to=mingo@elte.hu \
    --cc=akpm@linux-foundation.org \
    --cc=denys@visp.net.lb \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mel@csn.ul.ie \
    --cc=tglx@linutronix.de \
    /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