Hi! > > > Actually fuse allows SIGKILL, because it's always fatal, and the > > > syscall may not be restarted. > > > > I think you want to stick try_to_freeze() at the same places where you > > do SIGKILL handling. That should solve the 'syslogd is unfreezeable' > > problem. > > I could, but it would not solve the general problem. Namely, that the > presence of fuse imposes a certain ordering in which userspace tasks > have to be frozen. And it is not possible to know this ordering. We can just wait for all fuse requests to be serviced before proceeding further with freeze, right? > And even if the ordering were solved, the freezer would still not work > if the filesystem is not responding due to external events, such as a > lost network (this affects NFS, CIFS, whatever just the same as > fuse). That's ok, you can't suspend if your hdd is dead, and in the same way you can't suspend if your NFS server is dead. I agree it is ugly, but we seem to live ok with that. We could (and should?) handle that, probably by realizing that NFS is not a disk and using interruptible sleep, but... > > Plus, it would be nice to find out where suspend/hibernation is > > triggering fuse activity. We can then decide where to fix it -- in > > fuse or in suspend parts. You said sys_sync is not implemented... so > > where is the problem? > > I cannot say without having a sysrq-t of the situation. Yes please. Can someone affected please produce sysrq-t? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
