From: Ram Pai <linuxram@us.ibm.com>
To: Andrew Morton <akpm@osdl.org>
Cc: Miklos Szeredi <miklos@szeredi.hu>,
Al Viro <viro@ftp.linux.org.uk>,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 2/2] shared mounts: save mount flag space
Date: Mon, 28 Nov 2005 04:14:50 -0800 [thread overview]
Message-ID: <1133180090.3811.95.camel@localhost> (raw)
In-Reply-To: <20051126215509.073cb957.akpm@osdl.org>
On Sat, 2005-11-26 at 21:55, Andrew Morton wrote:
> Miklos Szeredi <miklos@szeredi.hu> wrote:
> >
> > Remaining mount flags are becoming scarce (just 11 bits)
> > and shared mount code uses 4 though one would suffice.
> >
> > I think this should go into 2.6.15, fixing it later would be breaking
> > userspace ABI.
>
> These seem sane objectives.
>
> > -static int do_change_type(struct nameidata *nd, int flag)
> > +static int do_change_type(struct nameidata *nd, int recurse, char *name)
> > {
> > struct vfsmount *m, *mnt = nd->mnt;
> > - int recurse = flag & MS_REC;
> > - int type = flag & ~MS_REC;
> > + enum propagation_type type;
> >
> > if (nd->dentry != nd->mnt->mnt_root)
> > return -EINVAL;
> >
> > + if (!name)
> > + return -EINVAL;
> > +
> > + if (strcmp(name, "unbindable") == 0)
> > + type = PT_UNBINDABLE;
> > + else if (strcmp(name, "private") == 0)
> > + type = PT_PRIVATE;
> > + else if (strcmp(name, "slave") == 0)
> > + type = PT_SLAVE;
> > + else if (strcmp(name, "shared") == 0)
> > + type = PT_SHARED;
> > + else
> > + return -EINVAL;
> > +
> > down_write(&namespace_sem);
> > spin_lock(&vfsmount_lock);
> > for (m = mnt; m; m = (recurse ? next_mnt(m, mnt) : NULL))
> > @@ -1302,8 +1315,8 @@ long do_mount(char *dev_name, char *dir_
> > data_page);
> > else if (flags & MS_BIND)
> > retval = do_loopback(&nd, dev_name, flags & MS_REC);
> > - else if (flags & (MS_SHARED | MS_PRIVATE | MS_SLAVE | MS_UNBINDABLE))
> > - retval = do_change_type(&nd, flags);
> > + else if (flags & MS_PROPAGATION)
> > + retval = do_change_type(&nd, flags & MS_REC, data_page);
> > else if (flags & MS_MOVE)
> > retval = do_move_mount(&nd, dev_name);
> > else
>
> But I don't know how much trauma this would cause. Hasn't util-linux
> already been patched with the new mount flags?
Andrew,
No. The new mount flags have not yet been picked up by
util-linux AFAIK.
and again with shared subtree semantics mount/umount command
can no way handle all the implicit mounts/unmounts that take
place without its knowledge. Dependence on /etc/mnttab is already
broken with namespaces. Shared-subtree adds some more misery.
I will work on that once I am back from vacation,
RP
>
> If it has, and if it uses the same names for these options, the patched
> mount(8) just won't work.
>
> The proposed new mount options should be documented somewhere.
>
> Anyway, I'll let Ram&Al decide on this proposal.
next prev parent reply other threads:[~2005-11-28 12:14 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-24 16:09 [PATCH 1/2] shared mounts: cleanup Miklos Szeredi
2005-11-24 16:18 ` [PATCH 2/2] shared mounts: save mount flag space Miklos Szeredi
2005-11-24 16:33 ` Miklos Szeredi
2005-11-27 5:55 ` Andrew Morton
2005-11-27 6:32 ` Al Viro
2005-11-27 9:34 ` Miklos Szeredi
2005-11-28 12:14 ` Ram Pai [this message]
2005-11-29 12:30 ` Rob Landley
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=1133180090.3811.95.camel@localhost \
--to=linuxram@us.ibm.com \
--cc=akpm@osdl.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=viro@ftp.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).