From: Amul Shah <amul.shah@unisys.com>
To: Andi Kleen <ak@suse.de>
Cc: LKML <linux-kernel@vger.kernel.org>,
fastboot <fastboot@lists.osdl.org>,
Vivek Goyal <vgoyal@in.ibm.com>
Subject: Re: [RFC] [PATCH 2.6.19-rc4] kdump panics early in boot when reserving MP Tables located in high memory
Date: Fri, 03 Nov 2006 09:55:21 -0500 [thread overview]
Message-ID: <1162565722.19677.68.camel@ustr-linux-shaha1.unisys.com> (raw)
In-Reply-To: <200611030340.55952.ak@suse.de>
On Fri, 2006-11-03 at 03:40 +0100, Andi Kleen wrote:
> 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);
Andi,
That won't worked because in arch/86_64/kernel/e820.c, the exactmap
parsing clobbers end_pfn_map.
static int __init parse_memmap_opt(char *p)
{
char *oldp;
unsigned long long start_at, mem_size;
if (!strcmp(p, "exactmap")) {
#ifdef CONFIG_CRASH_DUMP
/* If we are doing a crash dump, we
* still need to know the real mem
* size before original memory map is
* reset.
*/
saved_max_pfn = e820_end_of_ram();
#endif
end_pfn_map = 0;
e820.nr_map = 0;
userdef = 1;
return 0;
}
The following was my alternate patch with uses the saved_max_pfn
variable which avoids the MP config table reservation bug. I'll rewrite
it to go into reserve_bootmem_generic and submit that patch once I have
tested it.
I chose to use end_user_pfn because it is left unmodified unless the
user specifies an exactmap or a "mem=" value as a kernel boot parameter.
This might be a no-no, since I didn't check to see if I'm under the top
of memory. I'm making the assumption that since the user chose to
define memory the user knows what s/he is doing.
This patch is just for comment since I'll be using the same logic when I
update the patch that Andi sent.
thanks,
Amul
diff -Naur linux-2.6.19-rc4/arch/x86_64/kernel/mpparse.c linux-2.6.19-rc4-pfncheck/arch/x86_64/kernel/mpparse.c
--- linux-2.6.19-rc4/arch/x86_64/kernel/mpparse.c 2006-10-31 17:38:41.000000000 -0500
+++ linux-2.6.19-rc4-pfncheck/arch/x86_64/kernel/mpparse.c 2006-11-03 10:18:24.000000000 -0500
@@ -34,6 +34,7 @@
/* Have we found an MP table */
int smp_found_config;
unsigned int __initdata maxcpus = NR_CPUS;
+extern unsigned long end_user_pfn;
int acpi_found_madt;
@@ -528,6 +529,8 @@
extern void __bad_mpf_size(void);
unsigned int *bp = phys_to_virt(base);
struct intel_mp_floating *mpf;
+ int mpf_below_mem;
+ unsigned long mpf_pfn;
Dprintk("Scan SMP from %p for %ld bytes.\n", bp,length);
if (sizeof(*mpf) != 16)
@@ -542,8 +545,33 @@
|| (mpf->mpf_specification == 4)) ) {
smp_found_config = 1;
+ mpf_below_mem = 0;
reserve_bootmem_generic(virt_to_phys(mpf), PAGE_SIZE);
- if (mpf->mpf_physptr)
+ if (mpf->mpf_physptr) {
+ mpf_pfn = mpf->mpf_physptr>>PAGE_SHIFT;
+ mpf_below_mem = 1;
+#ifdef CONFIG_CRASH_DUMP
+ if (mpf_pfn > end_pfn &&
+ mpf_pfn < saved_max_pfn) {
+ printk(KERN_WARNING "WARNING: "
+ "mpf_physptr > end_pfn %lx in "
+ "user defined map\n", end_pfn);
+ printk(KERN_WARNING "WARNING: "
+ "Not reserving the MP Tables\n");
+ mpf_below_mem = 0;
+ }
+#endif
+ if (mpf_pfn > end_pfn &&
+ end_user_pfn != MAXMEM>>PAGE_SHIFT) {
+ printk(KERN_WARNING "WARNING: "
+ "mpf_physptr > end_pfn %lx. Try"
+ " a larger 'mem='\n", end_pfn);
+ printk(KERN_WARNING "WARNING: "
+ "Not reserving the MP Tables\n");
+ mpf_below_mem = 0;
+ }
+ }
+ if (mpf_below_mem)
reserve_bootmem_generic(mpf->mpf_physptr, PAGE_SIZE);
mpf_found = mpf;
return 1;
next prev parent reply other threads:[~2006-11-03 14:56 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-02 22:24 Amul Shah
2006-11-02 23:36 ` [Fastboot] " Vivek Goyal
2006-11-03 14:30 ` Amul Shah
2006-11-03 2:40 ` Andi Kleen
2006-11-03 14:55 ` Amul Shah [this message]
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=1162565722.19677.68.camel@ustr-linux-shaha1.unisys.com \
--to=amul.shah@unisys.com \
--cc=ak@suse.de \
--cc=fastboot@lists.osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=vgoyal@in.ibm.com \
/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
all inboxes | Powered by JetHome®