From: Al Viro <viro@ZenIV.linux.org.uk>
To: Aditya Kali <adityakali@google.com>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
anatol@google.com
Subject: Re: [RFC] vfs: avoid sb->s_umount lock while changing bind-mount flags
Date: Tue, 17 Sep 2013 03:40:40 +0100 [thread overview]
Message-ID: <20130917024040.GH13318@ZenIV.linux.org.uk> (raw)
In-Reply-To: <1379353350-11320-1-git-send-email-adityakali@google.com>
On Mon, Sep 16, 2013 at 10:42:30AM -0700, Aditya Kali wrote:
> During remount of a bind mount (mount -o remount,bind,ro,... /mnt/mntpt),
> we currently take down_write(&sb->s_umount). This causes the remount
> operation to get blocked behind writes occuring on device (possibly
> mounted somewhere else). We have observed that simply trying to change
> the bind-mount from read-write to read-only can take several seconds
> becuase writeback is in progress. Looking at the code it seems to me that
> we need s_umount lock only around the do_remount_sb() call.
> vfsmount_lock seems enough to protect the flag change on the mount.
> So this patch fixes the locking so that changing of flags can happen
> outside the down_write(&sb->s_umount).
What's to prevent mount -o remount,ro /mnt and mount -o remount,rw,nodev /mnt
racing and ending up with that sucker rw and without nodev? As for
lock_mount... nope - we carefully do *not* hold namespace_sem over any kind
of fs operations. Anything getting stuck while holding it will have
really nasty consequences.
So ->s_umount here is inelegant, but alternatives sucks worse...
next prev parent reply other threads:[~2013-09-17 2:40 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-16 17:42 [RFC] vfs: avoid sb->s_umount lock while changing bind-mount flags Aditya Kali
2013-09-17 2:40 ` Al Viro [this message]
2013-09-19 20:13 ` Aditya Kali
2013-09-30 17:54 ` Aditya Kali
2013-09-30 18:13 ` Aditya Kali
2013-09-30 20:03 ` Al Viro
2013-09-30 21:44 ` Aditya Kali
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=20130917024040.GH13318@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=adityakali@google.com \
--cc=anatol@google.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.