Messages in this thread | | | Subject | Re: [linux-pm] Re: [PATCH] Remove process freezer from suspend to RAM pathway | From | Miklos Szeredi <> | Date | Thu, 05 Jul 2007 12:14:07 +0200 |
| |
> > > > 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |