linux-kernel - [tip:x86/mm] x86, e820, pci: reserve extra free space near end of RAM

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] [day] [month] [year] [list]

Message-ID: <tip-45fbe3ee01b8e463b28c2751b5dcc0cbdc142d90@git.kernel.org>
Date:	Mon, 11 May 2009 09:51:45 GMT
From:	tip-bot for Linus Torvalds <torvalds@...ux-foundation.org>
To:	linux-tip-commits@...r.kernel.org
Cc:	linux-kernel@...r.kernel.org, hpa@...or.com, mingo@...hat.com,
	yinghai@...nel.org, torvalds@...ux-foundation.org,
	jesse.barnes@...el.com, yannick.roehlly@...e.fr,
	akpm@...ux-foundation.org, ink@...assic.park.msu.ru,
	tglx@...utronix.de, mingo@...e.hu
Subject: [tip:x86/mm] x86, e820, pci: reserve extra free space near end of RAM

Commit-ID:  45fbe3ee01b8e463b28c2751b5dcc0cbdc142d90
Gitweb:     http://git.kernel.org/tip/45fbe3ee01b8e463b28c2751b5dcc0cbdc142d90
Author:     Linus Torvalds <torvalds@...ux-foundation.org>
AuthorDate: Wed, 6 May 2009 08:06:44 -0700
Committer:  Ingo Molnar <mingo@...e.hu>
CommitDate: Mon, 11 May 2009 09:45:14 +0200

x86, e820, pci: reserve extra free space near end of RAM

The point is to take all RAM resources we have, and
_after_ we've added all the resources we've seen in
the E820 tree, we then _also_ try to add fake reserved
entries for any "round up to X" at the end of the RAM
resources.

[ Impact: improve PCI mem-resource allocation robustness, protect "stolen RAM" ]

Reported-by: Yannick Roehlly <yannick.roehlly@...e.fr>
Acked-by: Jesse Barnes <jesse.barnes@...el.com>
Signed-off-by: Yinghai Lu <yinghai@...nel.org>
Cc: Ivan Kokshaysky <ink@...assic.park.msu.ru>
Cc: Andrew Morton <akpm@...ux-foundation.org>
Cc: yannick.roehlly@...e.fr
LKML-Reference: <4A01A784.2050407@...nel.org>
Signed-off-by: Ingo Molnar <mingo@...e.hu>


---
 arch/x86/kernel/e820.c |   35 +++++++++++++++++++++++++++++++++++
 1 files changed, 35 insertions(+), 0 deletions(-)

diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
index 0062813..a2335d9 100644
--- a/arch/x86/kernel/e820.c
+++ b/arch/x86/kernel/e820.c
@@ -1371,6 +1371,23 @@ void __init e820_reserve_resources(void)
 	}
 }
 
+/* How much should we pad RAM ending depending on where it is? */
+static unsigned long ram_alignment(resource_size_t pos)
+{
+	unsigned long mb = pos >> 20;
+
+	/* To 64kB in the first megabyte */
+	if (!mb)
+		return 64*1024;
+
+	/* To 1MB in the first 16MB */
+	if (mb < 16)
+		return 1024*1024;
+
+	/* To 32MB for anything above that */
+	return 32*1024*1024;
+}
+
 void __init e820_reserve_resources_late(void)
 {
 	int i;
@@ -1382,6 +1399,24 @@ void __init e820_reserve_resources_late(void)
 			insert_resource_expand_to_fit(&iomem_resource, res);
 		res++;
 	}
+
+	/*
+	 * Try to bump up RAM regions to reasonable boundaries to
+	 * avoid stolen RAM:
+	 */
+	for (i = 0; i < e820.nr_map; i++) {
+		struct e820entry *entry = &e820_saved.map[i];
+		resource_size_t start, end;
+
+		if (entry->type != E820_RAM)
+			continue;
+		start = entry->addr + entry->size;
+		end = round_up(start, ram_alignment(start));
+		if (start == end)
+			continue;
+		reserve_region_with_split(&iomem_resource, start,
+						  end - 1, "RAM buffer");
+	}
 }
 
 char *__init default_machine_specific_memory_setup(void)
--
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/