2010/6/4 Matt Helsley <matthltc@xxxxxxxxxx>: > 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@xxxxxxxxxxxxx> 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. > 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> > >> 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. > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
