linux-kernel - Re: [PATCH] Only reset e820 once, even with multiple memmap=exactmap params

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:	Thu, 10 Jan 2013 09:26:43 -0500
From:	Vivek Goyal <vgoyal@...hat.com>
To:	Thomas Renninger <trenn@...e.de>
Cc:	Yinghai Lu <yinghai@...nel.org>,
	MUNEDA Takahiro <muneda.takahiro@...fujitsu.com>,
	Takao Indoh <indou.takao@...fujitsu.com>,
	linux-pci@...r.kernel.org, x86@...nel.org,
	linux-kernel@...r.kernel.org, andi@...stfloor.org,
	tokunaga.keiich@...fujitsu.com, kexec@...ts.infradead.org,
	hbabu@...ibm.com, mingo@...hat.com, ddutile@...hat.com,
	ishii.hironobu@...fujitsu.com, hpa@...or.com, bhelgaas@...gle.com,
	tglx@...utronix.de, khalid@...ehiking.org, horms@...ge.net.au
Subject: Re: [PATCH] Only reset e820 once, even with multiple memmap=exactmap
 params

On Thu, Jan 10, 2013 at 04:21:49AM +0100, Thomas Renninger wrote:
> On Tuesday, January 08, 2013 09:19:18 AM Yinghai Lu wrote:
> ...
> > 
> > that exactmap logic still have problem:
> > We need to check exactmap at first, aka need to scan the whole comand line
> > to see if exactmap is there at first and reset e820 tables then handle
> > other memmap opt.
> > 
> > Also please update your patch after
> > 
> > tip/x86/mm2
> > 
> > I have one patch that process memmap= with "," there.
> > 
> > http://git.kernel.org/?p=linux/kernel/git/tip/tip.git;a=commitdiff;h=9710f58
> > 1bb4c35589ac046b0cfc0deb7f369fc85
> > 
> > We could put exactmap scanning in new parse_memmap_opt.
> 
> I still do not understand why:
> 
> Kexec (kexec/firmware_memmap.c) is setting up the e820 map from:
> /sys/firmware/memmap/*

Kexe reads it from /sys/firmware/memmap/* because that's supposed to
be e820 map as passed by BIOS. And if user has specified some
command line options like mem=X, /sys/firmware/memmap/* is not truncated
but one exported using /proc/iomem is truncated accordingly.

So if we pass mem=1G in first kernel but not in second kernel, we want
second kernel to see whole of the system memory and not just 1G.

> and pass it via bootloader structures.

That's how bootloader is supposed to pass e820 memory map to kernel and
kexec is a bootloader.

> And this e820 table gets immediately voided by memmap=exactmap
> and a new one passed via boot parameters is set up.
> If I read this correctly, this is what happens?

This happens only in case of kdump and not kexec. In case of kdump
we want second kernel to use only selected memory areas.

In fact this is one improvement area. Instead of using memmap= entries
in kdump case, we should probably modify the e820 map passed in 
zero page and get rid of memmap= entries.

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/