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: <4A4966EF.6010809@kernel.org>
Date:	Mon, 29 Jun 2009 18:14:23 -0700
From:	Yinghai Lu <yinghai@...nel.org>
To:	"H. Peter Anvin" <hpa@...or.com>
CC:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>,
	Mikael Pettersson <mikpe@...uu.se>,
	Matthew Wilcox <matthew@....cx>,
	Grant Grundler <grundler@...isc-linux.org>,
	linux-kernel@...r.kernel.org, linux-pci@...r.kernel.org
Subject: Re: [BUG 2.6.31-rc1] HIGHMEM64G causes hang in PCI init on 32-bit
 x86

H. Peter Anvin wrote:
> Yinghai Lu wrote:
>>  			continue;
>> @@ -1409,8 +1409,10 @@ void __init e820_reserve_resources_late(
>>  		end = round_up(start, ram_alignment(start));
>>  		if (start == end)
>>  			continue;
>> -		reserve_region_with_split(&iomem_resource, start,
>> -						  end - 1, "RAM buffer");
>> +		if (end != (resource_size_t)end)
>> +			continue;
>> +		reserve_region_with_split(&iomem_resource, (resource_size_t)start,
>> +					  (resource_size_t)(end - 1), "RAM buffer");
>>  	}
>>  }
>>  
> 
> That doesn't quite look right; for one thing it doesn't handle the
> (admittedly somewhat unlikely) case of end pointing to the end of the
> address space.
> 
> Something like:
> 
> 	if (start > (resource_size_t)end-1)
> 		continue;
> 
> ... should work better.
> 

ok this one?

---
 arch/x86/kernel/e820.c |   16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

Index: linux-2.6/arch/x86/kernel/e820.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/e820.c
+++ linux-2.6/arch/x86/kernel/e820.c
@@ -1367,9 +1367,9 @@ 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)
+static u64 ram_alignment(u64 pos)
 {
-	unsigned long mb = pos >> 20;
+	u64 mb = pos >> 20;
 
 	/* To 64kB in the first megabyte */
 	if (!mb)
@@ -1400,17 +1400,17 @@ void __init e820_reserve_resources_late(
 	 * avoid stolen RAM:
 	 */
 	for (i = 0; i < e820.nr_map; i++) {
-		struct e820entry *entry = &e820_saved.map[i];
-		resource_size_t start, end;
+		struct e820entry *entry = &e820.map[i];
+		u64 start, end;
 
 		if (entry->type != E820_RAM)
 			continue;
 		start = entry->addr + entry->size;
-		end = round_up(start, ram_alignment(start));
-		if (start == end)
+		end = round_up(start, ram_alignment(start)) - 1;
+		if (start > (resource_size_t)end)
 			continue;
-		reserve_region_with_split(&iomem_resource, start,
-						  end - 1, "RAM buffer");
+		reserve_region_with_split(&iomem_resource, (resource_size_t)start,
+					  (resource_size_t)end, "RAM buffer");
 	}
 }
 
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ