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 12:17:57 -0500
From:	Vivek Goyal <vgoyal@...ibm.com>
To:	Andi Kleen <ak@...e.de>
Cc:	Amul Shah <amul.shah@...sys.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Fastboot mailing list <fastboot@...ts.osdl.org>
Subject: Re: [RFC] [PATCH 2.6.19-rc4] kdump panics early in boot when  reserving MP Tables located in high memory

On Fri, Nov 03, 2006 at 05:51:03PM +0100, Andi Kleen wrote:
> 
> [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.
> 

Hi Andi,

end_pfn_map still contins the highest address in e820. The only difference
is that it is reset and recalculated based on new memory map passed
with the help of memmap= options. 

Actually with mempmap=exactmap, we are overriding the BIOS provided 
memory map with a User defined memory map so we reset the end_pfn_map
to zero and it will be calculated again based on new memory map passed
with the help of memmap= options.

So to access all the firmware tables safely, one has to make sure that
right memmap= options have been passed to the kernel.

That's why IMHO, the right way to fix this problem is not doing
some special condition checks in kernel, instead, passing the right
memmap= options. To do that kexec-tools has to know where the firmware
tables are and that's why location of MP tables should be exported to 
user space.

Thanks
Vivek
-
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/