> > > > > > 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. > > > > > > Actually, why do you need this? There is no absolute need that you > > > finish the request. You must either finish the request or let yourself > > > be frozen. > > > > > > A quick look through fuse reveals principally request_wait_answer() > > > And maybe a few other places. Is there some hidden reason you cannot > > > handle being frozen here? > > > > 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? > > How probable is this situation? I guess it depends on usage patterns. I don't remember seeing any such cases, even though I have a permanent fuse mount, and I suspend regularly. But the fs is probably totally idle during suspend in my case. But some people use fuse as a home or root filesystem and in those cases it can become quite likely to cause problems. Miklos _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
