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 11:29:24 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	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,
	Yinghai Lu <yinghai@...nel.org>
Subject: Re: [BUG 2.6.31-rc1] HIGHMEM64G causes hang in PCI init on 32-bit
 x86

[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.

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