From: Jan Kara <jack@suse.cz>
To: Szeredi Miklos <miklos@szeredi.hu>
Cc: Jan Kara <jack@suse.cz>,
linux-fsdevel@vger.kernel.org, Al Viro <viro@zeniv.linux.org.uk>,
dchinner@redhat.com, sandeen@redhat.com,
Kamal Mostafa <kamal@canonical.com>
Subject: Re: [PATCH 07/19] fs: Add freezing handling to mnt_want_write() / mnt_drop_write()
Date: Thu, 29 Mar 2012 14:11:56 +0200 [thread overview]
Message-ID: <20120329121156.GD17298@quack.suse.cz> (raw)
In-Reply-To: <CAELBmZDYdU-mhGDsHRRVnfryWbV0QfgFvjNH=-OAx5DkJbkX5Q@mail.gmail.com>
On Thu 29-03-12 12:19:43, Szeredi Miklos wrote:
> On Thu, Mar 29, 2012 at 1:43 AM, Jan Kara <jack@suse.cz> wrote:
> > Most of places where we want freeze protection coincides with the places where
> > we also have remount-ro protection. So make mnt_want_write() and
> > mnt_drop_write() (and their _file alternative) prevent freezing as well.
> > For the few cases that are really interested only in remount-ro protection
> > provide new function variants.
>
> The underlying mechanism of mnt_want_write() and sb_start_write() is
> basically the same:
>
> - increment per-CPU counter
> - mb
> - check flag
> - retry loop for races
Well, __mnt_want_write() has the special handling of MNT_WRITE_HOLD.
Otherwise yes, the locking logic is rather similar.
> It is scalable but still there is a non-zero overhead, and duplicating
> it doesn't seem to make a lot of sense. Why not instead try to use a
> common abstraction for both?
I'm not sure here. Are you concerned about performance - i.e. you would
like to merge the remount-ro counter and topmost anti-freeze counter? That
cannot work because in some cases you want remount-ro protection but not
freezing protection. In particular when you have file open for writing,
you want to refuse remount-ro but still allow freezing.
If you are concerned about code / source size, the implementations of the
protection mechanisms could be possibly merged but I'm not sure it's worth
the hassle since we'd save like 50 LOC. MNT_WRITE_HOLD is one difference,
how each of the implementation detects whether we have succeeded in taking
our lock is another difference...
Honza
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR
next prev parent reply other threads:[~2012-03-29 12:12 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-28 23:43 [PATCH 00/19 v4] Fix filesystem freezing deadlocks Jan Kara
2012-03-28 23:43 ` [PATCH 01/19] mm: Make default vm_ops provide ->page_mkwrite handler Jan Kara
2012-03-28 23:43 ` [PATCH 02/19] fs: Push mnt_want_write() outside of i_mutex Jan Kara
2012-03-28 23:43 ` [PATCH 03/19] fat: " Jan Kara
2012-03-28 23:43 ` [PATCH 04/19] btrfs: " Jan Kara
2012-03-28 23:43 ` [PATCH 06/19] fs: Improve filesystem freezing handling Jan Kara
2012-03-28 23:43 ` [PATCH 07/19] fs: Add freezing handling to mnt_want_write() / mnt_drop_write() Jan Kara
2012-03-29 10:19 ` Szeredi Miklos
2012-03-29 12:11 ` Jan Kara [this message]
2012-03-29 12:34 ` Miklos Szeredi
2012-03-28 23:43 ` [PATCH 08/19] fs: Skip atime update on frozen filesystem Jan Kara
2012-03-28 23:43 ` [PATCH 09/19] fs: Protect write paths by sb_start_write - sb_end_write Jan Kara
2012-03-28 23:43 ` [PATCH 10/19] ext4: Convert to new freezing mechanism Jan Kara
2012-03-28 23:43 ` [PATCH 11/19] xfs: Convert to new freezing code Jan Kara
2012-03-28 23:43 ` [PATCH 12/19] ocfs2: Convert to new freezing mechanism Jan Kara
2012-03-28 23:43 ` [PATCH 13/19] gfs2: " Jan Kara
2012-03-29 10:38 ` Steven Whitehouse
[not found] ` <1332978214-15535-1-git-send-email-jack-AlSwsSmVLrQ@public.gmane.org>
2012-03-28 23:43 ` [PATCH 05/19] nfsd: Push mnt_want_write() outside of i_mutex Jan Kara
2012-03-28 23:43 ` [PATCH 14/19] fuse: Convert to new freezing mechanism Jan Kara
2012-03-28 23:43 ` [PATCH 16/19] nilfs2: " Jan Kara
2012-03-28 23:43 ` [PATCH 15/19] ntfs: " Jan Kara
2012-03-28 23:43 ` [PATCH 17/19] btrfs: " Jan Kara
2012-03-28 23:43 ` [PATCH 18/19] fs: Remove old " Jan Kara
2012-03-28 23:43 ` [PATCH 19/19] fs: Refuse to freeze filesystem with open but unlinked files Jan Kara
-- strict thread matches above, loose matches on Subject: below --
2012-03-05 16:00 [PATCH 00/19] Fix filesystem freezing deadlocks Jan Kara
2012-03-05 16:01 ` [PATCH 07/19] fs: Add freezing handling to mnt_want_write() / mnt_drop_write() Jan Kara
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=20120329121156.GD17298@quack.suse.cz \
--to=jack@suse.cz \
--cc=dchinner@redhat.com \
--cc=kamal@canonical.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=sandeen@redhat.com \
--cc=viro@zeniv.linux.org.uk \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).