linux-kernel - Re: [Patch v2] Make PCI extended config space (MMCONFIG) a driver opt-in

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.0.9999.0712271328010.21557@woody.linux-foundation.org>
Date:	Thu, 27 Dec 2007 13:37:41 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Loic Prylli <loic@...i.com>
cc:	Robert Hancock <hancockr@...w.ca>, Jeff Garzik <jeff@...zik.org>,
	Arjan van de Ven <arjan@...radead.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	gregkh@...e.de, linux-pci <linux-pci@...ey.karlin.mff.cuni.cz>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Martin Mares <mj@....cz>, Matthew Wilcox <matthew@....cx>,
	Kai Ruhnau <kai@...getaschen.dyndns.org>
Subject: Re: [Patch v2] Make PCI extended config space (MMCONFIG) a driver
 opt-in

On Thu, 27 Dec 2007, Loic Prylli wrote:
> 
> The root pcie port implementation is obviously buggy. But did we confirm
> whether that hardware bug might be partly related to
> "configuration-retry-status" pcie-root handling as introduced/described in:

Ahh, yes, that sounds like an excellent explanation of what might be going 
on.

Our code expects that the retry status is read as a 32-bit word that is 
0xffff0001, but you're right, that "0001" in the low-order bits is an 
interesting coincidence, and it may be that what the ATI pcie bridge 
does the high bits wrong.

The CRS docs *do* say that it has to return 0001h for the Vendor ID, but 
also that any additional bytes (ie the device ID) should be all ones. So 
we're doing the right thing from a spec standpoint, but as I often say: 
the spec doesn't count for anything, compared to reality.

> Does the 0001 vendor-id still shows up if pci_enable_crs() has never
> been called?

I don't believe we have ever tried, but it would be very interesting to 
hear. 

Kai, can you try that? Just remove the call to pci_enable_crs() in 
pci_scan_bridge() in drivers/pci/probe.c, and see if mmconfig starts 
working for you?

> Does anybody knows what was the original rational to call
> pci_enable_crs() by default?

.. another good question. I don't think anybody expected it to be broken, 
but if this turns out to be the thing that triggers it, I think we should 
disable CRS by default.

The code doesn't actually do what CRS is supposed to help with (ie go on 
to probe another device and then come back to the slow one later), so 
right now it's pretty much useless *anyway*. 

Matthew?

			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/