Date:	Mon, 7 Jun 2010 17:39:06 -0700
From:	Arve Hjønnevåg <arve@...roid.com>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...e.hu>, tytso@....edu,
	Brian Swetland <swetland@...gle.com>,
	Neil Brown <neilb@...e.de>,
	Alan Stern <stern@...land.harvard.edu>,
	Felipe Balbi <felipe.balbi@...ia.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Florian Mickler <florian@...kler.org>,
	Linux OMAP Mailing List <linux-omap@...r.kernel.org>,
	Linux PM <linux-pm@...ts.linux-foundation.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	James Bottomley <James.Bottomley@...e.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Kevin Hilman <khilman@...prootsystems.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Arjan van de Ven <arjan@...radead.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: suspend blockers & Android integration

2010/6/6 Rafael J. Wysocki <rjw@...k.pl>:
> On Sunday 06 June 2010, Arve Hjønnevåg wrote:
>> 2010/6/5 Rafael J. Wysocki <rjw@...k.pl>:
>> > On Saturday 05 June 2010, Arve Hjønnevåg wrote:
>> >> 2010/6/5 Thomas Gleixner <tglx@...utronix.de>:
>> >> > B1;2005;0cOn Fri, 4 Jun 2010, Arve Hjønnevåg wrote:
> ...
>> >
>> > Arve, we're still learning you have some more requirements we had no idea
>>
>> What new requirement are you talking about. Did you assume all our
>> user-space ipc calls went though a single process?
>
> No, but I didn't assume that your wakelock-holding processes depend on the
> other processes in a way that might prevent them from acquiring or dropping
> a wakelock.
>

It does not prevent it from acquiring a wakelock (assuming the already
held wakelock does not have a timeout), but it could delay it and
cause an error dialog to pop up stating that the fozen app is
misbehaving.

> ...
>> >> >> Trusted code that calls into untrusted code has to deal with the
>> >> >> untrusted code not responding, but we only want to pop up a message
>> >> >> that the application is not responding if it is misbehaving, not just
>> >> >> because it was frozen though no fault of its own.
>> >
>> > When Android starts opportunistic suspend, all applications are frozen,
>> > "trusted" as well as "untrusted", right?  So, after they are all frozen, none
>> > of them can do anything to prevent suspend from happening, right?
>>
>> Not if you mean when we write to /sys/power/state. Processes are not
>> frozen until the last suspend blocker is released.
>
> That doesn't matter.  In the opportunistic mode you don't need to write into
> /sys/power/state to start suspend, this is done by the kernel automatically as
> soon as the last wakelock has been released (at least this is my assumption
> about how this works).  Now, at this point the processes that don't use
> wakelocks can't really prevent themselves from being frozen and only the
> wakelocks users can do that.  So, if a wakelock user depends on a process
> that doesn't use wakelocks in such a way that (because of that dependence) it
> can't acquire its wakelock while processes are being frozen, things don't work
> as they are supposed to.
>
You seem to forget that we use overlapping wakelocks. A process that
need to acquire a wakelock does so before the driver it talks to
releases its wakelock. At this point no processes are frozen.

>> > Now, in my proposed approach the "untrusted" apps are frozen exactly at the
>> > point Android would start opportunistic suspend and they wouldn't be able
>> > to do anything about that anyway.  So if one of your "trusted" apps depends
>> > on the "untrusted" ones in a way that you describe, you alread have a bug
>> > (the "trusted" app cannot prevent automatic suspend from happening even if it
>> > wants, because it depends on an "untrusted" app that has just been frozen).
>> >
>>
>> I don't think what you said here is correct. If a wakeup event happens
>> all processed are unfrozen since the driver blocks suspend.
>
> This only means that the theoretical failure you gave as an example doesn't
> happen in practice.  No problem, then. :-)
>

If individual processes are frozen, we run into problems that we
cannot run into if we freeze and thaw all processes.

>> The app that reads this event blocks suspend before reading it. If it was
>> busy talking to a less trusted app when the event happened it still works
>> since all apps are running at this point.
>
> And how is this different from an approach with cgroup freezing?  Apps that
> use wakelock within the current framework would use "freeze locks" to prevent
> the "untrusted" part of user space from being frozen or to thaw it.  Where's
> the problem, then?
>

They will not be able to get wakeup events directly from the kernel.
If the kernel does not thaw processes when a wakeup event happens, the
app may never get to the point where it grabs its wakelock.

-- 
Arve Hjønnevåg
--
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/

Powered by blists - more mailing lists