linux-kernel - Re: Attempted summary of suspend-blockers LKML thread

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:	Sat, 7 Aug 2010 10:49:37 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	Arve Hjønnevåg <arve@...roid.com>,
	Matthew Garrett <mjg59@...f.ucam.org>, david@...g.hm,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Arjan van de Ven <arjan@...radead.org>,
	linux-pm@...ts.linux-foundation.org, linux-kernel@...r.kernel.org,
	pavel@....cz, florian@...kler.org, swetland@...gle.com,
	peterz@...radead.org, tglx@...utronix.de, alan@...rguk.ukuu.org.uk
Subject: Re: Attempted summary of suspend-blockers LKML thread

On Saturday, August 07, 2010, Rafael J. Wysocki wrote:
> On Friday, August 06, 2010, Alan Stern wrote:
> > On Thu, 5 Aug 2010, Arve Hjønnevåg wrote:
> ...
> > But what sorts of things qualify as wakeup events?  Right now, the code
> > handles only events coming by way of the PME# signal (or its platform
> > equivalent).  But that signal usually gets activated only when a PCI
> > device is in a low-power mode; if the device is at full power then it
> > simply generates an IRQ.  It's the same event, but reported to the
> > kernel in a different way.  So consider...
> > 
> > Case 1: The system is suspending and the PCI device has already been
> > 	placed in D3hot when an event occurs.  PME# is activated,
> > 	the wakeup event is reported, the suspend is aborted, and the 
> > 	system won't try to suspend again for at least 100 ms.  Good.
> > 
> > Case 2: The system is running normally and the PCI device is at full
> > 	power when an event occurs.  PME# isn't activated and 
> > 	pm_wakeup_event doesn't get called.  Then when the system
> > 	tries to suspend 25 ms later, there's nothing to prevent it
> > 	even though the event is still being processed.  Bad.
> > 
> > In case 2 the race has not been resolved.  It seems to me that the 
> > only proper solution is to call pm_wakeup_event for _every_ PCI 
> > interrupt.  This may be too much to add to a hot path, but what's the 
> > alternative?
> 
> Arguably not every PCI interrupt should be regarded as a wakeup event, so
> I think we can simply say in the cases when that's necessary the driver should
> be responsible for using pm_wakeup_event() or pm_stay_awake() / pm_relax() as
> appropriate.
> 
> My patch only added it to the bus-level code which covered the PME-based
> wakeup events that _cannot_ be handled by device drivers.

Also please note that it depends a good deal on the definition of a "wakeup
event".  Under the definition used when my patch was being developed, ie. that
wakeup events are the events that would wake up the system from a sleep state,
PCI interrupts cannot be wakeup events, unless the given device remains in the
full power state although the system has been suspended (standard PCI devices
are not allowed to generate signals except for PME from low-power states).

Thanks,
Rafael
--
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/