linux-kernel - Re: PCI resource problems caused by improper address rounding

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:	Tue, 18 Dec 2007 13:46:56 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Ivan Kokshaysky <ink@...assic.park.msu.ru>
cc:	Chuck Ebbert <cebbert@...hat.com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Daniel Ritz <daniel.ritz@....ch>, Greg KH <greg@...ah.com>
Subject: Re: PCI resource problems caused by improper address rounding

On Wed, 19 Dec 2007, Ivan Kokshaysky wrote:
> 
> Doh. Let's fix the kernel first...
> 
> Does this make any difference? (the patch is self explaining ;-)

Heh, indeed. Good catch - that

	Prefetchable memory behind bridge: 0000000000000000-000000000fffffff

on device 00:01.0 does look totally broken, and it would make more sense 
if it matched what the device has (and what /proc/iomem resports).

That said, Intel bridges tend to be transparent even when they *claim* 
normal decode, so I wonder whether it actually matters in this case. But 
your patch looks very obviously right. 

So maybe the rest of the kernel and X both already did everything right, 
and it was just this stupid bridge setup thing that was broken (and 
forcing the IOMEM resource to below the 4G mark just hid it).

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