On Tuesday, 3 July 2007 13:07, Oliver Neukum wrote: > Am Dienstag, 3. Juli 2007 schrieb Miklos Szeredi: > > > > So to summarize, the plan that makes things work with fuse is: > > > > > > > > - For STR, don't do the freezer thing. > > > > > > > > - For STD, don't sys_sync() after you froze > > > > > > > > There might be -other- issues, but that should get you through some of > > > > > > At the risk of repeating myself. Character device drivers are written > > > with the assumption that normal io and suspend/resume do not race > > > with each other due to the freezer. > > > What do you intend to do about that? > > > > Oliver, can you please explain your worries in a bit more detail? > > > > I don't claim to know anything about how STR or hibernate works, but > > neither seem to have any problem with I/O on the fuse device "racing" > > with them. > > The problem is not with fuse. The problem is generic in nature. > > If you remove the freezer, user space remains active until the last CPU > goes into suspend. It can do syscalls. Or do you know a clean way to exempt > only the tasks fuse might use? > > Now device drivers have a guaranteed temporal sequence: > > last io -> suspend() -> resume() [or disconnect()] -> new io > > This is because suspend() is called after the freezer goes into action. If > you remove the freezer, you need to deal with > > 1. io to suspended devices > 2. resume() assuming that the device is in the state suspend() left it > 3. io changing a device's state while suspend is saving it > > and you need to fix this for all device drivers, not just those fuse is > involved with. Removing the freezer means doing a more or less full > audit of every driver and additional locking in many drivers. Agreed. Greetings, Rafael -- "Premature optimization is the root of all evil." - Donald Knuth _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
