Messages in this thread | | | Subject | Re: [PATCH 2/2] shared mounts: save mount flag space | From | Ram Pai <> | Date | Mon, 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/
| |