linux-kernel - [PATCH 2/2] x86 e820: Introduce memmap=resetusablemap for kdump usage

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:	Tue, 22 Jan 2013 16:20:49 +0100
From:	Thomas Renninger <trenn@...e.de>
To:	hpa@...or.com
Cc:	yinghai@...nel.org, x86@...nel.org, linux-kernel@...r.kernel.org,
	kexec@...ts.infradead.org, vgoyal@...hat.com, horms@...ge.net.au,
	Thomas Renninger <trenn@...e.de>
Subject: [PATCH 2/2] x86 e820: Introduce memmap=resetusablemap for kdump usage

From: Yinghai Lu <yinghai@...nel.org>

kdump voided the whole original e820 map and half way made
it up via memmap= options passed via kdump boot params again.

But this is conceptionally wrong. The whole original memory ranges
which are declared reserved, ACPI data/nvs or however are not usable
must stay the same and get honored by the kdump kernel.

Therefore memmap=resetusablemap gets introduced.
kdump passes this one and only the usable e820 ranges are removed.
kdump passes the usable ranges to use via memmap=x@y parameter(s).
The not usable e820 ranges are preserved.

This for example fixes mmconf (extended PCI config access) and
possibly other kernel parts which rely on remapped memory to be
in reserved or ACPI (data/nvs) declared e820 memory areas.

Tested-by: Thomas Renninger <trenn@...e.de>
Reviewed-by: Thomas Renninger <trenn@...e.de>
Signed-off-by: Thomas Renninger <trenn@...e.de>
---
 Documentation/kernel-parameters.txt |    9 +++++++++
 arch/x86/kernel/e820.c              |   13 +++++++++++--
 2 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 9776f06..fe2f677 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1498,6 +1498,15 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
 			BIOS output or other requirements. See the memmap=nn@ss
 			option description.
 
+	memmap=resetusablemap
+			[KNL,X86] Similar to exactmap, but instead of discarding
+			the whole original e820 map, only the usable memory
+			areas are ignored.
+			Those must be passed via memmap=X@Y parameters,
+			reserved, ACPI and ACPI NVS areas are preserved.
+			This boot parameter is intended for kdump usage.
+			Also passing exactmap overrules resetusablemap.
+
 	memmap=nn[KMG]@ss[KMG]
 			[KNL] Force usage of a specific region of memory
 			Region of memory to be used, from ss to ss+nn.
diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
index dc0b9f0..4e0ef9d 100644
--- a/arch/x86/kernel/e820.c
+++ b/arch/x86/kernel/e820.c
@@ -845,7 +845,7 @@ static int __init parse_memmap_one(char *p)
 	if (!p)
 		return -EINVAL;
 
-	if (!strncmp(p, "exactmap", 8)) {
+	if (!strncmp(p, "exactmap", 8) || !strncmp(p, "resetusablemap", 14)) {
 		if (exactmap_parsed)
 			return 0;
 
@@ -858,7 +858,11 @@ static int __init parse_memmap_one(char *p)
 		 */
 		saved_max_pfn = e820_end_of_ram_pfn();
 #endif
-		e820.nr_map = 0;
+		if (!strncmp(p, "resetusablemap", 14)) {
+			/* remove all old E820_RAM ranges */
+			e820_remove_range(0, ULLONG_MAX, E820_RAM, 1);
+		} else
+			e820.nr_map = 0;
 		userdef = 1;
 		return 0;
 	}
@@ -890,6 +894,11 @@ static int __init parse_memmap_opt(char *str)
 	p = strstr(p, "exactmap");
 	if (p)
 		parse_memmap_one("exactmap");
+	else {
+		p = strstr(boot_command_line, "resetusablemap");
+		if (p)
+			parse_memmap_one("resetusablemap");
+	}
 
 	while (str) {
 		char *k = strchr(str, ',');
-- 
1.7.6.1

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