From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matt Helsley Subject: Re: suspend blockers & Android integration Date: Fri, 4 Jun 2010 18:18:26 -0700 Message-ID: <20100605011826.GB21016@count0.beaverton.ibm.com> References: <20100603193045.GA7188@elte.hu> <20100603232302.GA16184@elte.hu> <1275644619.27810.39462.camel@twins> <201006050138.30859.rjw@sisk.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Arve =?iso-8859-1?B?SGr4bm5lduVn?= Cc: Thomas Gleixner , "Rafael J. Wysocki" , Peter Zijlstra , Ingo Molnar , tytso@mit.edu, Brian Swetland , Neil Brown , Alan Stern , Felipe Balbi , LKML , Florian Mickler , Linux OMAP Mailing List , Linux PM , Alan Cox , James Bottomley , Linus Torvalds , Kevin Hilman , "H. Peter Anvin" , Arjan van de Ven List-Id: linux-omap@vger.kernel.org On Fri, Jun 04, 2010 at 05:39:17PM -0700, Arve Hj=F8nnev=E5g wrote: > On Fri, Jun 4, 2010 at 5:05 PM, Thomas Gleixner = wrote: > > On Sat, 5 Jun 2010, Rafael J. Wysocki wrote: >=20 > > =A0 =A0 With the cgroup freezer you can "suspend" them right away a= nd > > =A0 =A0 just keep the trusted background task(s) alive which allows= us to > > =A0 =A0 go into deeper idle states instead of letting the crapplica= tions > > =A0 =A0 run unconfined until the download finished and the suspend > > =A0 =A0 blocker goes away. > > >=20 > 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. =20 > 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 t= o 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 the= n you've very likely got a "bad" dependency. =46or example, say a trusted app plans on doing a blocking read() to fe= tch the output of an untrusted app via a pipe. Assuming we know the untrust= ed app's pid we could then check the dependency and determine that we're l= ikely to block because the untrusted app's freezer cgroup is FREEZING or FROZ= EN. (certain to block if we see FROZEN) That said, it involves quite a few system calls compared to a simple re= ad() from the pipe. So my guess is it would be a debugging tool at best -- n= ot 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