linux-kernel - Re: [PATCH] x86 e820: only void usable memory areas in memmap=exactmap case

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]

Message-Id: <201301141605.43428.trenn@suse.de>
Date:	Mon, 14 Jan 2013 16:05:43 +0100
From:	Thomas Renninger <trenn@...e.de>
To:	Yinghai Lu <yinghai@...nel.org>
Cc:	"H. Peter Anvin" <hpa@...or.com>,
	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,
	vgoyal@...hat.com, ishii.hironobu@...fujitsu.com,
	bhelgaas@...gle.com, tglx@...utronix.de, khalid@...ehiking.org,
	horms@...ge.net.au
Subject: Re: [PATCH] x86 e820: only void usable memory areas in memmap=exactmap case

On Monday, January 14, 2013 03:43:46 AM Yinghai Lu wrote:
> On Sun, Jan 13, 2013 at 6:08 PM, Thomas Renninger <trenn@...e.de> wrote:
> > On Saturday, January 12, 2013 09:07:12 AM Yinghai Lu wrote:
...
> everyone could understand it straightforward:
> exactmap:  memmap will be specified, and it should be honored without
> considering old any memmap.
> exactusablemap: will make sure only old ram range get removed, and
> specified usable ranges will become final usable
> ranges in the final memmap. so we need to remove overlapping to old
> reserved ranges.
> 
> aka: exact means EXACT ...
The naming is not my point...
Anyway after a quick talk with Alexander Graf, I guess I won't have
much of a chance: rule is rule and a boot param is a public interface
which must not change just like that (deprecation phase, etc.).

...
 
> those just some kind of improvement without considering kdump.
> because kdump/scripts already does good job to provide right exactmap
> with usable and acpi reserved areas.
No it's conceptional wrong to provide the reserved areas via memmap
while the original ones are declared already via boot loader structures.

There are store ACPI NVS memory in suspend/resume workarounds (suspend does not
fit that much for kdump, but there may be more than this and mmconf).
The reserved areas in kdump kernel should be the same than with the
original e820 table to avoid any unforseen issues.
And kdump got them already passed and should use this info.

> for mmconf, some system that range reserved in e820, and some have that in ACPI.
> and those systems will have that mmconf enabled in kdumped kernel.

 
> attached is what I like to have with exactusablemap, but maybe is not
> needed, and we can just stay with exactmap...
> 
> ps: we don't need to add e820_remove_type...
I thought this tiny loop:
+       for (i = 0; i < e820.nr_map; i++) {
+               struct e820entry *ei = &e820.map[i];
+               if (ei->type == type) {
+                       memset(ei, 0, sizeof(struct e820entry));
+                       continue;
+               }
+       }
would be easier to evaluate what it's doing (cmp to.
e820_remove_range(0, ULLONG_MAX, E820_RAM, 1);)
But I do not have a strong opinion on that.

What is this for?:
@@ -871,6 +879,11 @@ static int __init parse_memmap_one(char
 	userdef = 1;
 	if (*p == '@') {
 		start_at = memparse(p+1, &p);
+		if (exactusablemap_parsed) {
+			/* remove all range with other types */
+			e820_remove_range(start_at, mem_size,
+						 E820_RAM, 0);
+		}
 		e820_add_region(start_at, mem_size, E820_RAM);
 	} else if (*p == '#') {
 		start_at = memparse(p+1, &p);


    Thomas
--
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/