linux-kernel - Re: [Regression] PCI resources allocation problem on HP nx6325

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: <alpine.LFD.2.01.0908050902300.3390@localhost.localdomain>
Date:	Wed, 5 Aug 2009 09:25:23 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Manuel Lauss <mano@...rinelk.homelinux.net>
cc:	"Rafael J. Wysocki" <rjw@...k.pl>,
	Matthew Wilcox <willy@...ux.intel.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Linux PCI <linux-pci@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Andrew Patterson <andrew.patterson@...com>
Subject: Re: [Regression] PCI resources allocation problem on HP nx6325



On Wed, 5 Aug 2009, Manuel Lauss wrote:
> 
> On Tue, Aug 04, 2009 at 04:04:16PM -0700, Linus Torvalds wrote:
> > 
> > So I _think_ that you actually are getting the same layout as with 2.6.30, 
> > but with a warning that didn't exist in 2.6.30. Can you verify?
> 
> You're absolutely correct: /proc/iomem on 2.6.30 and 31-rc5+ are identical,
> the only difference being 2.6.30 not complaining about any collisions.

Ok.

So this is not a regression per se.

The warning looks a bit annoying, but in fact I believe that the warning 
is correct, and is showing us a real problem. Well, not "problem" exactly, 
but an issue.

I think that what is happening is that pci_find_parent_resource() may be 
in fact finding another parent resource than the one we strictly want (the 
pre-existing one).

And I think it's brought on by the fact that this is a ROM resource.

I bet that what is happening is:

 - the PCI bridge has a _prefetchable_ bus resource window at

	ff600000-ff6fffff : PCI Bus 0000:02

 - the PCI bridge is a transparent bridge

 - the BIOS has set up the ROM (BAR 6) at 

	ff680000-ff69ffff : 0000:02:03.0

 - We have for some reason marked the ROM as being non-prefetchable.

and what happens is:

 - pci_find_parent_resource() refuses to use the ff600000-ff6fffff PCI 
   bridge resource, because it is marked IORESOURCE_PREFETCH, and the ROM 
   resource is not so marked.

 - But because it's a transparent bridge, once we've iterated over the 
   bridge window resources, we have a couple of resources that point back 
   to the parent of the bridge - the PCI root resources. 

   So now pci_find_parent_resource() will return that instead

 - request_resource() will (correctly) notice that the root resource 
   already has other resources at that address (the PCI brige window!) and 
   will refuse to insert it - leading us to re-allocating the 
   BIOS-provided resource later (to the non-prefetchable bus window)

 - but when we for a short while (incorrectly) used 'insert_resource()' in 
   pci_claim_resource(), it would recurse back into the prefetchable 
   window, and everything would work - because a ROM resource is actually 
   perfectly happy to be in a prefetchable window.

So I think I understand the behavior on your box, and the warning was 
actually correct and useful - our PCI layer is being stupid. We should 
mark ROM resources as being prefetchable.

Hmm.. We do seem to _try_ do exactly that in pci_read_bases(). I wonder 
what I'm missing, and where that bit is then cleared. Or whether we're 
doing that ROM BAR probe somewhere else too..

		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/