On Fri, 31 Oct 2008, Nigel Cunningham wrote: > You don't. You just use FUSE_MIGHT_FREEZE to stop them before they take > locks that might cause problems. So my suggestion is: Before? FUSE_MIGHT_FREEZE is called _after_ i_mutex is taken by the VFS. > 1) Stop new requests at FUSE_MIGHT_FREEZE > 2) Handle existing requests by using freezer_do_not_count in > request_send and request_send_nowait before the spin_lock and > freezer_count after the spin_unlock. > > With #2, we don't need to care about whether the request is completed > before freezing completes or post-resume. > > If the userspace process tries to use an already frozen fuse filesystem > and gets frozen, that's okay because we'll sit waiting for an answer, > not be counted by the freezer and so not contribute to any failure to > freeze processes. > > If the userspace process completes its work, we'll either get caught at > the freezer_count (if we've already been told to freeze) or be gotten > later, after exiting the fuse code. Yes, this is the variant of categorizing sleeps to freezing and non-freezing. The problem is, you need to do that with all mutex_lock(&inode->i_mutex) instances as well. Try grepping for that in fs/*.c! It _is_ possible, it's just not practical. Miklos _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
