> > Ok, I'll just blame fuse here. 'You have to write to /sys > > files for SIGKILL to work' is not funny. > > SIGKILL won't work on a stopped task. Neither on a traced task. > Neither on a zombie (how many newbies are thoroughly confused about > that ;) > > And it won't work on a task that is hanging on an NFS mount, when the > network broke. > > Oh, and it won't work on a deadlocked fuse filesystem. How many of > these have you met? How many of the others? And maybe someday, when I'm feeling _really_ bored, I may start hacking the VFS to make it possible for tasks to be killed while waiting on a mutex. Can a task doing a page fault be interrupted? I don't see why not. But, it's _not_ going to happen now, to fix the problems with suspend. Hacking fuse (however broken it may be) or the VFS is not the right way to fix those problems. It may be easier than fixing the drivers, though I doubt it. But even if it's the easier way it's not the _right_ way. We want the various subsystems in the kernel to be less dependent on each other not more. And the freezer is just adding unnecessary dependence on totally unrelated code. And that does not only impact fuse, but a lot of other code in the kernel, in the form of try_to_freeze() calls all over the place. Is that so hard to understand? You can bash fuse all you want, I really don't mind. But please stop trying to prove, that this situation is best handled in fuse. It just won't happen, not because I'm lazy to do the work but because I don't have the guts to do something so obviously wrong. Miklos _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
