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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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

On Wednesday, August 04, 2010, Matthew Garrett wrote:
> On Wed, Aug 04, 2010 at 11:30:44AM -0700, david@...g.hm wrote:
> > a couple days ago I made the suggestion to put non-privilaged tasks in a  
> > cgroup so that the idle/suspend decision code could ignore acitivity  
> > caused by this cgroup.
> >
> > in the second version wakeup events would be 'activity' that would be  
> > counted and therefor the system would not be idle. As for the race with  
> > suspending and new things happening, wouldn't that be handled the same 
> > way that it is in a normal linux box?
> 
> No! And that's precisely the issue. Android's existing behaviour could 
> be entirely implemented in the form of binary that manually triggers 
> suspend when (a) the screen is off and (b) no userspace applications 
> have indicated that the system shouldn't sleep, except for the wakeup 
> event race. Imagine the following:
> 
> 1) The policy timeout is about to expire. No applications are holding 
> wakelocks. The system will suspend providing nothing takes a wakelock.
> 2) A network packet arrives indicating an incoming SIP call
> 3) The VOIP application takes a wakelock and prevents the phone from 
> suspending while the call is in progress
> 
> What stops the system going to sleep between (2) and (3)? cgroups don't, 
> because the voip app is an otherwise untrusted application that you've 
> just told the scheduler to ignore.

I _think_ you can use the just-merged /sys/power/wakeup_count mechanism to
avoid the race (if pm_wakeup_event() is called at 2)).

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/