> > 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. 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). > 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. > > > That's very special, and maybe even a FUSE bug. And that is also > > > what makes FUSE special w.r.t. s2ram. > > > > What makes fuse special is that some file operations are synchronous > > and non-restartable. That's just how the UNIX filesystem API works > > and is hardly a bug in fuse. > > Well, unix is not plan9, and maybe userland filesystems are impossible > in unix. But that is hardly a bug in unix :-). I'd rather say, reliable suspend to ram is impossible in the presense of userspace filesystems, iff people are too lazy to fix the suspend framework and the drivers to work without the freezer. This has nothing to do with unix, if plan9 would need to support STR or hibernate, it would face exactly the same problems. Miklos _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
