linux-kernel - Re: [RFC] [PATCH 2.6.19-rc4] kdump panics early in boot when reserving MP Tables located in high memory

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 3 Nov 2006 17:51:03 +0100
From:	Andi Kleen <ak@...e.de>
To:	Amul Shah <amul.shah@...sys.com>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Vivek Goyal <vgoyal@...ibm.com>
Subject: Re: [RFC] [PATCH 2.6.19-rc4] kdump panics early in boot when  reserving MP Tables located in high memory


[Finally dropping that annoying fastboot list from cc. Please never include any closed 
mailing lists in l-k posts. Thanks]

>   That won't worked because in arch/86_64/kernel/e820.c, the exactmap
> parsing clobbers end_pfn_map.

That's a bug imho. It shouldn't do that.

end_pfn_map should be always the highest address in e820 so that we 
can access all firmware tables safely.

-Andi

> 
> 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;
> 	}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/