linux-kernel - Re: [linux-pm] Bug in PCI core

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:	Fri, 13 Oct 2006 22:33:04 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
cc:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Matthew Wilcox <matthew@....cx>, Adam Belay <abelay@....EDU>,
	Arjan van de Ven <arjan@...radead.org>,
	Greg KH <greg@...ah.com>, <linux-pci@...ey.karlin.mff.cuni.cz>,
	Linux-pm mailing list <linux-pm@...ts.osdl.org>,
	Kernel development list <linux-kernel@...r.kernel.org>
Subject: Re: [linux-pm] Bug in PCI core

On Sat, 14 Oct 2006, Benjamin Herrenschmidt wrote:

> Well, we have two different things here.
> 
> One is short term block. For example, PM transitions, or BIST. In that
> case, I reckon it might be worth just making the user space PCI config
> space accessors block in the kernel during the transition (a wait
> queue ?)

That seems like a reasonable thing to do.  (BTW, can anyone explain 
quickly what "BIST" means?)

> One is long term block: the device is off. That's where it becomes
> tricky. For D3, I suppose it's actually correct to return cached infos
> provided that those do actually cache the PM capability indicating D3
> state (that is we need to update the cache after the transition). And
> it's correct to prevent writes too I suppose.
> 
> Then there are problems with things like embedded or some Apple ASICs
> where we toggle power/clock lines of devices but not directly using PCI
> PM (in fact, those devices might not even have PCI PM capability
> exposed). Returning cached info is fine, but we can't tell userland
> about the powered off (or unclocked) state of the device that way.

Now you're starting to tread in the dangerous waters of runtime PM
userspace APIs.  So far nobody has figured out a good general way of
exposing internal power states to userspace.  There may not even be such a 
thing.

Alan Stern

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