Message-ID: <20100605011826.GB21016@count0.beaverton.ibm.com>
Date:	Fri, 4 Jun 2010 18:18:26 -0700
From:	Matt Helsley <matthltc@...ibm.com>
To:	Arve Hjønnevåg <arve@...roid.com>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	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>
Subject: Re: suspend blockers & Android integration

On Fri, Jun 04, 2010 at 05:39:17PM -0700, Arve Hjønnevåg wrote:
> On Fri, Jun 4, 2010 at 5:05 PM, Thomas Gleixner <tglx@...utronix.de> wrote:
> > On Sat, 5 Jun 2010, Rafael J. Wysocki wrote:

<snip>

> 
> >     With the cgroup freezer you can "suspend" them right away and
> >     just keep the trusted background task(s) alive which allows us to
> >     go into deeper idle states instead of letting the crapplications
> >     run unconfined until the download finished and the suspend
> >     blocker goes away.
> >
> 
> Yes this would be better, but I want it in addition to suspend, not
> instead of it. It is also unclear if our user-space code could easily
> make use of it since our trusted code calls into untrusted code.
>

Perhaps I'm misunderstanding, but suspend and the cgroup freezer
interoperate well today -- you don't have to choose one or the other.
If you've discovered otherwise I'd consider it a bug and would like to
hear more about it.

<snip> 

> it can handle bad apps better (assuming you don't combine
> opportunistic suspend and cgroup freezing).

I don't see why that would be a problem. The cgroup freezer works
independently of the suspend freezer -- even with suspend blockers.
So my hunch is this is really the same as the next problem you refer to:

> The biggest hurdle is how
> to handle dependencies between processes that gets frozen and
> processes that don't get frozen.

I'm not sure it covers everything you want, but it should be possible to
identify some of those so long as you know which process you're
communicating with.

A trusted app can look up the freezer cgroup of a target app in /proc, then
look at the cgroup's freezer.state file. If it's FREEZING or FROZEN then
you've very likely got a "bad" dependency.

For example, say a trusted app plans on doing a blocking read() to fetch
the output of an untrusted app via a pipe. Assuming we know the untrusted
app's pid we could then check the dependency and determine that we're likely
to block because the untrusted app's freezer cgroup is FREEZING or FROZEN.
(certain to block if we see FROZEN)

That said, it involves quite a few system calls compared to a simple read()
from the pipe. So my guess is it would be a debugging tool at best -- not
something you always have enabled.

It may even be possible to make an lsof-like debugging tool to do that from
outside both apps.

Cheers,
	-Matt Helsley
--
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