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 -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
