> > > > And teach VFS to block suspension, while waiting on a mutex held by > > > > another process performing a fuse operation. > > > > > > > > I can already hear the beautiful praise from Al Viro at the sight of > > > > that ;) > > > > > > There is that. > > > > > > OK, bite the bullet. Tasks involved in fuse are special. Give them a flag > > > and teach the freezer to put them on ice only after all other task are > > > frozen. In a way they are kernel, there's no use denying that. > > > > And flag every other process, that the flagged process is > > communicating with? How are you proposing to do that? > > > > Quoting Paul: > > > > "1. The freezer cannot be guaranteed deadlock-free without constructing > > a dependency graph between tasks (both user and kernel), which is > > virtually impossible since the dependencies are not externally > > observable." > > A deadlock requires that the circular wait is uninterruptible. Normal IPC > isn't. > > What are you doing in the userland portions of fuse? Some kind of IPC > with other tasks? Anything, writing to a file, writing to shared memory, sending things over the network. There's no limit to what a filesystem daemon may do. It's a perfectly ordinary unprivileged userspace process. And this is a feature not a bug. > There is a limit to which you can push kernel functionality into > user space. Limiting what a userspace filesystem can do would defeat the whole purpose of the bloody thing. This is not negotiable ;) Miklos _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm