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]

Message-ID: <20100805073359.4cb791c0@schatten.dmk.lab>
Date:	Thu, 5 Aug 2010 07:33:59 +0200
From:	Florian Mickler <florian@...kler.org>
To:	paulmck@...ux.vnet.ibm.com
Cc:	david@...g.hm,
	Arve Hjønnevåg <arve@...roid.com>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Arjan van de Ven <arjan@...radead.org>,
	linux-pm@...ts.linux-foundation.org, linux-kernel@...r.kernel.org,
	pavel@....cz, 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 Wed, 4 Aug 2010 16:10:03 -0700
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com> wrote:

> On Wed, Aug 04, 2010 at 03:56:42PM -0700, david@...g.hm wrote:
> > On Wed, 4 Aug 2010, Arve Hj?nnev?g wrote:
> > 
> > >On Wed, Aug 4, 2010 at 3:31 PM,  <david@...g.hm> wrote:
> > >>On Wed, 4 Aug 2010, Matthew Garrett wrote:
> > >>
> > >>>On Wed, Aug 04, 2010 at 10:51:07PM +0200, Rafael J. Wysocki wrote:
> > >>>>
> > >>>>On Wednesday, August 04, 2010, Matthew Garrett wrote:
> > >>>>>
> > >>>>>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)).
> > >>>
> > >>>Yes, I think that solves the problem. The only question then is whether
> > >>>it's preferable to use cgroups or suspend fully, which is pretty much up
> > >>>to the implementation. In other words, is there a reason we're still
> > >>>having this conversation? :) It'd be good to have some feedback from
> > >>>Google as to whether this satisfies their functional requirements.
> > >>
> > >>the proposal that I nade was not to use cgroups to freeze some processes and
> > >>not others, but to use cgroups to decide to ignore some processes when
> > >>deciding if the system is idle, stop everything or nothing. cgroups are just
> > >>a way of easily grouping processes (and their children) into different
> > >>groups.
> > >
> > >That does not avoid the dependency problem. A process may be waiting
> > >on a resource that a process you ignore owns. I you ignore the process
> > >that owns the resource and enter idle when it is ready to run (or
> > >waiting on a timer), you are still effectively blocking the other
> > >process.
> > 
> > and if you don't have a wakelock the same thing will happen. If you
> > expect the process to take a while you can set a timeout to wake up
> > every 30 seconds or so and wait again, this would be enough to
> > prevent you from going to sleep (or am I misunderstanding how long
> > before you go into suspend without a wakelock set, see my other
> > e-mail for the full question)
> 
> The difference between the Android scheme and your proposal is that the
> Android scheme freezes -all- the processes, not just a subset of them.
> Therefore, in the Android scheme, the case of one process attempting to
> acquire a resource held by a frozen process.  In contrast, any scheme
> that attempts to freeze only a subset of the processes must somehow
> either avoid or properly handle the situation where a frozen process is
> holding a resource that a running process is trying to acquire.
> 
> 							Thanx, Paul

No no. In the David-Lang-CGroup-Scheme[1](tm?) suspend-from-idle
is used. For idle decision a certain subset of tasks is ignored. 

Where suspend is prevented by the trusted
process in android-world taking a wakelock, here it would just prevent
the system from going idle by arming timers.

This would be pretty equivalent to the suspend-blocker scheme and not
introduce new userspace api. But the downside is, as Arve pointed out,
that now one can not get full-idle-power-leverage while suspend
is blocked. 

[1] http://permalink.gmane.org/gmane.linux.kernel/1018452  and
following 


Cheers,
Flo

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