> > > > 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. Fuse is not involved with _any_ device drivers. It is fully unaware of suspend issues and I think that's how it should stay ;) > Removing the freezer means doing a more or less full > audit of every driver and additional locking in many drivers. How about a "CONFIG_NOFREEZE (experimental): only turn this on if you want to fix buggy drivers that can fail during suspend with the freezer turned off"? I'm guessing quite a few kernel developers would be willing to turn on such an option. Miklos _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
