Re: [PATCH 03/34] VFS: Add CL_NO_SLAVE flag to clone_mnt()/copy_tree()

[Valerie Aurora <vaurora@redhat.com>]

On Sun, Sep 19, 2010 at 10:25:53PM -0700, Ram Pai wrote:
> 
> I understand your intentions, but I think you are making a wrong assumption.
> You seem to be thinking that if a slave-mount is cloned, the new cloned
> mount will also be a slave-mount and will hence receive propagations. As
> per shared subtree semantics, a slave-mount when cloned will create a private
> mount. Since your intention is to avoid generating any new mounts that 
> recieve propagations, you should be checking for shared-mounts and 
> slave-shared-mounts because these are the two kind of mounts that when
> cloned create new mounts that receive propagation.

No.  This isn't about the semantics of the clone mount operation.  It
is about the administrator creating a slave mount, unioning it, and
then being surprised when the unioned file system does not receive
mount propagation events.

Think of the source vfsmount tree as a set of command line arguments
for the union mount.

> > One of the reasons I had to do it this way is that you can't hold
> > vfsmount_lock while calling copy_tree(), so the mount flags can change
> > between the first check in #2 and the copy_tree() in #3.  Also
> > sb->s_flag can change.  
> 
> Isn't this whole operation done under the protection of namespace_sem? 
> I know that shared/slave flags can't change if the namespace_sem is held. 
> The same may also be true for sb->s_flag. 

namespace_sem only covers the shared/slave mount flags.  We also care
about MNT_READONLY, which is protected by vfsmount_lock.  sb->s_flags
is protected by sb->s_umount and not namespace_sem.

We could do the shared/slave check outside of clone_mnt(), but it
would require two passes over the source vfsmount tree.

> > One of the problems with the current code is
> > that it can't deal with cloning existing union mounts, which we need
> > if we are to make bind mounts work (see do_loopback()).
> 
> if I understand your union mount semantics correctly, you dont' allow the
> same filesystem to be union mounted rw in two different locations. correct?
> If yes, then bind mount of a union-mount has to be disallowed.

A bind mount of part of a union file system (which is itself unioned
and includes the lower layers) doesn't have the same problems as an
independent mount of the rw layer.  Mainly, the union stack will be
the same for both.  I'm not sure it will work but it won't fail for
the same reasons as a separate mount of the rw layer alone.

-VAL