lkml.org 
[lkml]   [2005]   [Nov]   [28]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 2/2] shared mounts: save mount flag space
FromRam Pai <>
DateMon, 28 Nov 2005 04:14:50 -0800
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.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-11-28 13:17    [from the cache]
©2003-2008