linux-kernel - Re: [BUG 2.6.31-rc1] HIGHMEM64G causes hang in PCI init on 32-bit x86

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:	Mon, 29 Jun 2009 16:29:00 -0700
From:	Yinghai Lu <yinghai@...nel.org>
To:	"H. Peter Anvin" <hpa@...or.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>, Mikael Pettersson <mikpe@...uu.se>
CC:	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

Yinghai Lu wrote:
> H. Peter Anvin wrote:
>> [Add Cc: Yinghai]
>>
>> Mikael Pettersson wrote:
>>>  > >  > 
>>>  > >  > OK, this seems more than a wee bit strange, to say the least.  We
>>>  > >  > shouldn't be reserving the entire address space; this is legitimate I/O
>>>  > >  > space.
>>>  > >  > 
>>>  > >  > However, the reservation suddenly being improper for the root resource
>>>  > >  > would definitely make things unhappy...
>>>  > > 
>>>  > > Reverting the two e820 changes in 2.6.31-rc1,
>>>  > > 5d423ccd7ba4285f1084e91b26805e1d0ae978ed and then
>>>  > > 45fbe3ee01b8e463b28c2751b5dcc0cbdc142d90,
>>>  > > but keeping the iomem_resource.end cap change, makes 2.6.31-rc1
>>>  > > work on my HIGHMEM64G machine.
>>>  > > 
>>>  > > Seems the e820 and the iomem_resource.end changes are Ok in
>>>  > > isolation but break when combined.
>>>  > 
>>>  > With the e820 change reverted, what does /proc/iomem look like?
>>>
>> OK.  This is starting to make sense.  I suspect this is a similar issue
>> as 3b0fde0fac19c180317eb0601b3504083f4b9bf5 addresses, which is that the
>> e820 code assumes -- and I don't see any exception to that in
>> 45fbe3ee01b8e463b28c2751b5dcc0cbdc142d90 -- that iomem_resource covers
>> the entire 64-bit address space that e820 knows.  I wonder what happens
>> with "interestingly shaped" memory above 4 GB if resource_size_t is 32
>> bits with that code.
>>
>> In terms of address space assignment, an alternate implementation of the
>> address space cap is to mark it reserved; that would unfortunately
>> result in an ugly turd at the end of /proc/iomem, but that can be
>> addressed if need be, too.

Mikael, can you try following patch on your system?

---
 arch/x86/kernel/e820.c |   10 ++++++----
 1 file changed, 6 insertions(+), 4 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
@@ -1400,8 +1400,8 @@ 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;
@@ -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");
 	}
 }
 
--
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/