> Yes, fuse could handle being frozen there. However that would only > solve part of the problem: an operation waiting for a reply could be > holding a VFS mutex and some other task may be blocked on that mutex. > > How would you solve freezing those tasks? That task is implicitely frozen... but the kernel doesn't know it and thus the freezer timeouts or fails or deadlocks or whatever. The freezer could be made to ignore tasks that are sleeping in the kernel assuming that if they go out of it, they'll ultimately reach do_signal and freeze, but that means they can potentially still issues IOs which is what the freezer tries to avoid ... Or the kernel could start tracking dependencies, but then, good luck implementing that crap. At the end of the day, I stand my ground, the freezer cannot be made reliable without massive infrastructure changes or giving up on very useful features such as fuse among others. Besides, it only partially "hides" the problem of requests going to drivers, thus it's a bad solutions. We would be much better off spending time fixing the drivers to properly block requests after suspended, and that also gives for free the ability to do dynamic runtime suspend on them. And for "trivial" drivers where we don't care, using late_suspend to power the chip off later when IRQs are off is an easy enough way to solve it with very little code (though won't help with dynamic PM but that's not necessarily an issue). No need for a freezer either way. Ben. _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
