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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 27 Dec 2007 21:37:49 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
cc:	Loic Prylli <loic@...i.com>, 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>,
	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 Fri, 28 Dec 2007, Benjamin Herrenschmidt wrote:
> 
> I have embedded boards where proper CRS operations is critical since the
> kernel brings the PCIe link up itself, and thus is likely to hit devices
> still in the middle of CRS.

.. but that's perfectly fine. A PCI-E bridge will certainly retry it in 
hardware (or it isn't a PCI-E bridge!).

The CRS bit in question is purely the *software*visible* bit - ie whether 
the OS gets told about the delay or not. As long as the OS then just 
retries the same device, enabling CRS SV is pointless.

So I'm going to disable that thing. If there is some _other_ PCI-E bridge 
that is simply buggy, and cannot handle the hw retry itself or is just 
otherwise dodgy, we can have a white-list for cases where it really needs 
to be done, but the current code is just bogus.

			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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ