linux-kernel - Removing PCI CRS code could cause problems

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>] [day] [month] [year] [list]

Date:	Sun, 20 Jan 2008 07:35:47 -0700
From:	Matthew Wilcox <matthew@....cx>
To:	Linus Torvalds <torvalds@...l.org>
Cc:	Greg KH <greg@...ah.com>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	linux-pci@...ey.karlin.mff.cuni.cz, linux-kernel@...r.kernel.org
Subject: Removing PCI CRS code could cause problems

I just remembered why I put in the software-visible Config Retry Status
code.  With conventional PCI, devices must return within something like
2^25 clock cycles (about a second for 33MHz busses).  PCIe devices can
return CRS to the root complex which will automatically retry -- but to
the CPU, this looks like a read that hasn't returned yet.

My concern was/is that devices which take a long time to initialise may
cause watchdog timers to fire.  I don't know if there's some CPUs which
might enter error recovery, but I think the native Linux watchdog might
well trigger.

Now, I have no evidence that this is going to happen.  And we definitely
have buggy hardware to contend with (that caused the initial reversion).
But the commit ad7edfe0490877864dc0312e5f3315ea37fc4b3a isn't as risk-free
as it might seem.

Would you accept a patch which just black-listed the bridge that was
causing problems?  Or possibly we don't even need that if we take Ivan's
patch to use conf1 accesses instead of mmconf for conventional config
space -- I understand the device in question to only have problems when
CRS is combined with mmconfig.

-- 
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."
--
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/