2010/6/6 Rafael J. Wysocki <rjw@xxxxxxx>: > On Sunday 06 June 2010, Arve Hjønnevåg wrote: >> 2010/6/5 Rafael J. Wysocki <rjw@xxxxxxx>: >> > On Saturday 05 June 2010, Arve Hjønnevåg wrote: >> >> 2010/6/5 Thomas Gleixner <tglx@xxxxxxxxxxxxx>: >> >> > 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-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
