LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Nigel Cunningham <ncunningham@crca.org.au>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: linux-pm@lists.linux-foundation.org, linux-kernel@vger.kernel.org
Subject: Re: [linux-pm] Freezer: Don't count threads waiting for frozen	filesystems.
Date: Fri, 31 Oct 2008 22:28:04 +1100	[thread overview]
Message-ID: <1225452484.6574.35.camel@nigel-laptop> (raw)
In-Reply-To: <E1Kvq72-00049W-O1@pomaz-ex.szeredi.hu>

Hi again.

On Fri, 2008-10-31 at 10:16 +0100, Miklos Szeredi wrote:
> On Fri, 31 Oct 2008, Nigel Cunningham wrote:
> > Hi.
> > 
> > On Fri, 2008-10-31 at 09:49 +0100, Miklos Szeredi wrote:
> > > On Fri, 31 Oct 2008, Nigel Cunningham wrote:
> > > > I'm not sure that's true. You see, I'm thinking of this as not that
> > > > different to the problem of unmounting filesystems. There, too, we need
> > > > to unmount in a particular order, and let transactions on each
> > > > filesystem stop cleanly before we can unmount them. Even if there are
> > > > differences, perhaps looking at how we handle unmounting will help with
> > > > handling freezing.
> > > 
> > > There's nothing magic about umount, it just uses a refcount on the fs.
> > > 
> > > But umount changes the namespace, that's the big difference.  For
> > > example if a process is accessing path P which has a component inside
> > > the mount, it _will_ get different results before and after the
> > > umount.  This is not acceptable for freezing.
> > > 
> > > For freezing to work with such a refcounting scheme, we'd have to
> > > count _future_ uses of the fs as well, not just current ones, which is
> > > obviously impossible.
> > 
> > I must be missing something. If you're freezing future users of the
> > filesystem before they can start anything new, doesn't that deal with
> > this problem?
> 
> How do you determine which are the future users?

You don't. You just use FUSE_MIGHT_FREEZE to stop them before they take
locks that might cause problems. So my suggestion is:

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.

Regards,

Nigel


  reply	other threads:[~2008-10-31 11:28 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1224886068.6478.21.camel@nigel-laptop>
2008-10-26 20:01 ` Rafael J. Wysocki
2008-10-27 11:12   ` Miklos Szeredi
2008-10-27 11:20     ` Nigel Cunningham
2008-10-27 11:37       ` Rafael J. Wysocki
2008-10-27 11:40         ` Nigel Cunningham
2008-10-27 12:38           ` Miklos Szeredi
2008-10-27 20:59             ` Nigel Cunningham
2008-10-27 21:09               ` Miklos Szeredi
2008-10-27 22:13                 ` Nigel Cunningham
2008-10-28 20:25                   ` Miklos Szeredi
2008-10-28 21:29                     ` Nigel Cunningham
2008-10-28 21:51                       ` Miklos Szeredi
2008-10-28 22:00                         ` Rafael J. Wysocki
2008-10-28 22:02                           ` Miklos Szeredi
2008-10-28 22:21                             ` Rafael J. Wysocki
2008-10-28 23:21                               ` Miklos Szeredi
2008-10-28 23:59                                 ` Rafael J. Wysocki
2008-10-29  8:10                                   ` Miklos Szeredi
2008-10-29 13:51                                     ` Alan Stern
2008-10-29 14:50                                       ` Miklos Szeredi
2008-10-29 15:28                                         ` Alan Stern
2008-10-29 15:50                                           ` Miklos Szeredi
2008-10-29 16:17                                             ` Alan Stern
2008-10-29 16:10                                           ` Miklos Szeredi
2008-10-29 20:37                                             ` Alan Stern
2008-10-29 21:11                                               ` Rafael J. Wysocki
2008-10-29 21:45                                                 ` Nigel Cunningham
2008-10-29 22:07                                                   ` Rafael J. Wysocki
2008-10-29 23:53                                                     ` Miklos Szeredi
2008-11-09 13:44                                                       ` Pavel Machek
2008-10-29 23:48                                                   ` Miklos Szeredi
2008-10-30 13:04                                                     ` Nigel Cunningham
2008-10-30 13:56                                                       ` Alan Stern
2008-10-30 21:44                                                         ` Nigel Cunningham
2008-10-31  8:49                                                           ` Miklos Szeredi
2008-10-31  9:10                                                             ` Nigel Cunningham
2008-10-31  9:16                                                               ` Miklos Szeredi
2008-10-31 11:28                                                                 ` Nigel Cunningham [this message]
2008-10-31 12:44                                                                   ` Miklos Szeredi
2008-10-31 21:11                                                                     ` Nigel Cunningham
2008-10-29 23:43                                               ` Miklos Szeredi
2008-10-30 13:54                                                 ` Alan Stern
2008-10-30 14:39                                                   ` Miklos Szeredi
2008-10-30 17:07                                                     ` Alan Stern
2008-10-30 17:43                                                       ` Miklos Szeredi
2008-10-30 20:17                                                     ` Rafael J. Wysocki
2008-11-15 16:58                                                     ` Pavel Machek
2008-10-29 23:56                                               ` Matthew Garrett
2008-10-28 22:03                         ` Nigel Cunningham
2008-10-28 23:04                     ` Nigel Cunningham
2008-10-28 23:12                       ` Miklos Szeredi
2008-10-28 23:17                         ` Nigel Cunningham
2008-10-28 23:24                           ` Miklos Szeredi
2008-10-28 23:41                             ` Nigel Cunningham
2008-10-28 23:45                               ` Miklos Szeredi
2008-10-28 23:50                                 ` Miklos Szeredi
2008-10-28 23:58                                   ` Nigel Cunningham
2008-10-28 23:54                                 ` Nigel Cunningham
2008-10-27 11:37       ` Miklos Szeredi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1225452484.6574.35.camel@nigel-laptop \
    --to=ncunningham@crca.org.au \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@lists.linux-foundation.org \
    --cc=miklos@szeredi.hu \
    --subject='Re: [linux-pm] Freezer: Don'\''t count threads waiting for frozen	filesystems.' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).