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. ... > >> >> 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. > > 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. :-) > 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? Rafael -- 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
