Re: suspend blockers & Android integration

2010/6/4 Matt Helsley [off-list ref]:

On Fri, Jun 04, 2010 at 05:39:17PM -0700, Arve Hjønnevåg wrote:

quoted

On Fri, Jun 4, 2010 at 5:05 PM, Thomas Gleixner [off-list ref] wrote:

quoted

On Sat, 5 Jun 2010, Rafael J. Wysocki wrote:

<snip>

quoted

quoted

    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.

I'm not aware of any bug with combining both, but we cannot use
suspend at all without suspend blockers in the kernel (since wakeup
events may be ignored) and I don't know how we can safely freeze
cgroups without funneling all potential wakeup events through a
process that never gets frozen.

<snip>

quoted

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:

quoted

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.

I don't think they are "bad" dependencies. Our framework has to
communicate with apps.

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

-- 
Arve Hjønnevåg