linux-kernel - [PATCH] x86_32: fix regression caused by trim ram according to mtrr on system with 4G more 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 for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-id: <200802060149.26083.yinghai.lu@sun.com>
Date:	Wed, 06 Feb 2008 01:49:25 -0800
From:	Yinghai Lu <Yinghai.Lu@....COM>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Pavel Emelyanov <xemul@...nvz.org>,
	"Kok, Auke" <auke-jan.h.kok@...el.com>, jesse.brandeburg@...el.com,
	jeffrey.t.kirsher@...el.com, john.ronciak@...el.com,
	David Miller <davem@...emloft.net>,
	Linux Netdev List <netdev@...r.kernel.org>,
	e1000-devel@...ts.sourceforge.net, Denis Lunev <den@...nvz.org>,
	Justin Piszcz <jpiszcz@...idpixels.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: [PATCH] x86_32: fix regression caused by trim ram according to mtrr on
 system with 4G more RAM

[PATCH] x86_32: fix regression caused by trim ram according to mtrr on system with 4G more RAM

Pravel report:
"
The commit

        093af8d7f0ba3c6be1485973508584ef081e9f93
        x86_32: trim memory by updating e820

broke my e1000 card: on loading driver says that

        e1000: probe of 0000:04:03.0 failed with error -5

and the interface doesn't appear.
"

on 32 bit kernel, base will overflow when try to do PAGE_SHIFT.
and highest_addr will always less 4G.

so use pfn instead of address to avoid overflow when more than 4g
 ram installed on 32bit kernel
Many thanks for Pavel Emelyanov to report and test it.

Signed-off-by: Yinghai Lu <yinghai.lu@....com>
Tested-by: Pavel Emelyanov <xemul@...nvz.org>

diff --git a/arch/x86/kernel/cpu/mtrr/main.c b/arch/x86/kernel/cpu/mtrr/main.c
index 1e27b69..4e7490f 100644
--- a/arch/x86/kernel/cpu/mtrr/main.c
+++ b/arch/x86/kernel/cpu/mtrr/main.c
@@ -659,7 +659,7 @@ static __init int amd_special_default_mtrr(void)
  */
 int __init mtrr_trim_uncached_memory(unsigned long end_pfn)
 {
-	unsigned long i, base, size, highest_addr = 0, def, dummy;
+	unsigned long i, base, size, highest_pfn = 0, def, dummy;
 	mtrr_type type;
 	u64 trim_start, trim_size;
 
@@ -682,28 +682,27 @@ int __init mtrr_trim_uncached_memory(unsigned long end_pfn)
 		mtrr_if->get(i, &base, &size, &type);
 		if (type != MTRR_TYPE_WRBACK)
 			continue;
-		base <<= PAGE_SHIFT;
-		size <<= PAGE_SHIFT;
-		if (highest_addr < base + size)
-			highest_addr = base + size;
+		if (highest_pfn < base + size)
+			highest_pfn = base + size;
 	}
 
 	/* kvm/qemu doesn't have mtrr set right, don't trim them all */
-	if (!highest_addr) {
+	if (!highest_pfn) {
 		printk(KERN_WARNING "WARNING: strange, CPU MTRRs all blank?\n");
 		WARN_ON(1);
 		return 0;
 	}
 
-	if ((highest_addr >> PAGE_SHIFT) < end_pfn) {
+	if (highest_pfn < end_pfn) {
 		printk(KERN_WARNING "WARNING: BIOS bug: CPU MTRRs don't cover"
 			" all of memory, losing %LdMB of RAM.\n",
-			(((u64)end_pfn << PAGE_SHIFT) - highest_addr) >> 20);
+			(end_pfn - highest_pfn) >> (20 - PAGE_SHIFT));
 
 		WARN_ON(1);
 
 		printk(KERN_INFO "update e820 for mtrr\n");
-		trim_start = highest_addr;
+		trim_start = highest_pfn;
+		trim_start <<= PAGE_SHIFT;
 		trim_size = end_pfn;
 		trim_size <<= PAGE_SHIFT;
 		trim_size -= trim_start;
--
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/