Hi. On Fri, 2008-10-31 at 13:44 +0100, Miklos Szeredi wrote: > 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. Ok. So I'll shift it backwards in the calling chain a bit. > > 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. Let's get practical. You know fuse a lot better than me. Can you give me the most complicated, ugly configuration you can think of, and I'll work on making it freeze first time, every time. Regards, Nigel _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
