Hi.

On Fri, 2008-10-31 at 13:44 +0100, Miklos Szeredi wrote:
quoted text
> 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.

quoted text
> > 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

--
unsubscribe notice
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/