All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@suse.de>
To: Amul Shah <amul.shah@unisys.com>
Cc: LKML <linux-kernel@vger.kernel.org>, fastboot <fastboot@lists.osdl.org>
Subject: Re: [RFC] [PATCH 2.6.19-rc4] kdump panics early in boot when reserving MP Tables located in high memory
Date: Fri, 3 Nov 2006 03:40:55 +0100	[thread overview]
Message-ID: <200611030340.55952.ak@suse.de> (raw)
In-Reply-To: <1162506272.19677.33.camel@ustr-linux-shaha1.unisys.com>

On Thursday 02 November 2006 23:24, Amul Shah wrote:

> 
> The ACPI tables and MP Tables reside higher in memory.  When reserving
> memory with reserve_bootmem_generic, the function has a BUG panic if the
> memory location to reserve is above the top of memory.  The MP table is
> above the top of memory in a user defined memory map.

I think it would be cleaner to add a check in reserve_bootmem_generic
that just returns when pfn >= end_pfn && pfn < end_pfn_mapped

How about this patch? Does it work?

-Andi

Handle reserve_bootmem_generic beyond end_pfn

This can happen on kexec kernels with some configurations, in particularly
on Unisys ES7000 systems.

Analysis by Amul Shah 

Cc: Amul Shah <amul.shah@unisys.com>

Signed-off-by: Andi Kleen <ak@suse.de>

Index: linux/arch/x86_64/mm/init.c
===================================================================
--- linux.orig/arch/x86_64/mm/init.c
+++ linux/arch/x86_64/mm/init.c
@@ -655,9 +655,22 @@ void free_initrd_mem(unsigned long start
 
 void __init reserve_bootmem_generic(unsigned long phys, unsigned len) 
 { 
-	/* Should check here against the e820 map to avoid double free */ 
 #ifdef CONFIG_NUMA
 	int nid = phys_to_nid(phys);
+#endif
+	unsigned long pfn = phys >> PAGE_SHIFT;
+	if (pfn >= end_pfn) {
+		/* This can happen with kdump kernels when accessing firmware
+		   tables. */
+		if (pfn < end_pfn_map) 
+			return;
+		printk(KERN_ERR "reserve_bootmem: illegal reserve %lx %u\n",
+				phys, len);
+		return;
+	}
+
+	/* Should check here against the e820 map to avoid double free */ 
+#ifdef CONFIG_NUMA
   	reserve_bootmem_node(NODE_DATA(nid), phys, len);
 #else       		
 	reserve_bootmem(phys, len);    


  parent reply	other threads:[~2006-11-03  2:40 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-02 22:24 [RFC] [PATCH 2.6.19-rc4] kdump panics early in boot when reserving MP Tables located in high memory Amul Shah
2006-11-02 23:36 ` [Fastboot] " Vivek Goyal
2006-11-03 14:30   ` Amul Shah
2006-11-03  2:40 ` Andi Kleen [this message]
2006-11-03 14:55   ` Amul Shah
2006-11-03 16:51     ` Andi Kleen
2006-11-03 17:17       ` Vivek Goyal
2006-11-03 19:47         ` Amul Shah
2006-11-03 19:52           ` Andi Kleen
2006-11-03 21:17             ` Amul Shah
2006-11-03 22:01               ` Andi Kleen
2006-11-03 17:40       ` Vivek Goyal
2006-11-03 18:43         ` Andi Kleen
2006-11-03 18:51           ` Vivek Goyal

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=200611030340.55952.ak@suse.de \
    --to=ak@suse.de \
    --cc=amul.shah@unisys.com \
    --cc=fastboot@lists.osdl.org \
    --cc=linux-kernel@vger.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.