From: Al Viro <viro@ftp.linux.org.uk>
To: Ram <linuxram@us.ibm.com>
Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
akpm@osdl.org, miklos@szeredi.hu, mike@waychison.com,
bfields@fieldses.org, serue@us.ibm.com
Subject: Re: [RFC PATCH 5/10] vfs: shared subtree aware bind mounts
Date: Tue, 20 Sep 2005 08:17:41 +0100 [thread overview]
Message-ID: <20050920071741.GI7992@ftp.linux.org.uk> (raw)
In-Reply-To: <20050916182619.GA28489@RAM>
On Fri, Sep 16, 2005 at 11:26:19AM -0700, Ram wrote:
This patch needs to be split *AND* accompanied by locking rules. It's
pretty much the core of the entire thing; if it's possible to offload
chunks elsewhere, life would become easier. Locking rules are badly
needed, along with the comments re "why can't that mntput()/dput()
block under a spinlock", etc.
BTW, how are you dealing with MS_MOVE?
> +void do_detach_prepare_mnt(struct vfsmount *mnt)
> +{
> + mnt->mnt_mountpoint->d_mounted--;
> + mntput(mnt->mnt_parent);
> + dput(mnt->mnt_mountpoint);
> + mnt->mnt_parent = mnt;
> +}
General note: mntput() should go _after_ dput() when we deal with pairs.
Doesn't cost anything, trivially safe.
> if (res) {
> spin_lock(&vfsmount_lock);
> + clean_propagation_reference(res);
Uh-oh... What makes that safe? We do mntput() here; are we guaranteed
that these pointers won't be the last references?
> + spin_lock(&vfspnode_lock);
> + propagate_abort_mount(m);
Calls do_detach_prepare() -> dput(), mntput(). At the very least such
cases need comments...
> +static void __do_make_private(struct vfsmount *mnt)
> +{
> + __do_make_slave(mnt);
> + list_del_init(&mnt->mnt_slave);
> + mnt->mnt_master = NULL;
> + set_mnt_private(mnt);
> +}
> +
> int do_make_private(struct vfsmount *mnt)
> {
> /*
> * a private mount is nothing but a
> * slave mount with no incoming
> * propagations.
> */
> spin_lock(&vfspnode_lock);
> - __do_make_slave(mnt);
> - list_del_init(&mnt->mnt_slave);
> + __do_make_private(mnt);
> spin_unlock(&vfspnode_lock);
> - mnt->mnt_master = NULL;
> - set_mnt_private(mnt);
> return 0;
> }
Why not do that from the very beginning, BTW?
> /*
> - * a unclonable mount is nothing but a
> + * a unclonable mount is a
> * private mount which is unclonnable.
> */
> spin_lock(&vfspnode_lock);
> - __do_make_slave(mnt);
> - list_del_init(&mnt->mnt_slave);
> + __do_make_private(mnt);
> spin_unlock(&vfspnode_lock);
> - mnt->mnt_master = NULL;
> set_mnt_unclonable(mnt);
> return 0;
> }
next prev parent reply other threads:[~2005-09-20 7:17 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-16 18:26 [RFC PATCH 5/10] vfs: shared subtree aware bind mounts Ram
2005-09-20 7:17 ` Al Viro [this message]
2005-09-20 7:56 ` Ram Pai
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=20050920071741.GI7992@ftp.linux.org.uk \
--to=viro@ftp.linux.org.uk \
--cc=akpm@osdl.org \
--cc=bfields@fieldses.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxram@us.ibm.com \
--cc=mike@waychison.com \
--cc=miklos@szeredi.hu \
--cc=serue@us.ibm.com \
/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.