On Thursday, 5 July 2007 21:44, Miklos Szeredi wrote: > > Am Donnerstag, 5. Juli 2007 schrieb Miklos Szeredi: > > > > > 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? Greetings, Rafael -- "Premature optimization is the root of all evil." - Donald Knuth _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
