Mounting on floating mounts is possible
PATCH 1/1 Mounting on floating mounts is possible
Hi,
this[1] patch changed check_mnt() so that mounting on a floating mount (i.e. one that was unmounted using MNT_DETACH and was still in use) is possible, since we no longer check if the mountpoint is actually reachable. The problem is that we may lose any reference to the floating mount, but the mount on it will keep it alive, thus it will never go away. The following patch removes the reference from the mount to its namespace when it is unmounted lazily, so that check_mnt protects from such mounts.
Please CC me as I'm not subscribed to the list.
Bjoern
[1] http://lwn.net/Articles/91946/
fs/namespace.c 2004-11-06 04:38:37.299013810 +0100 renamed from fs/namespace.c 2004-10-31 00:41:02.000000000 +0200 +1 -0
@@ -358,6 +358,7 @@ } else { struct nameidata old_nd; detach_mnt(mnt, &old_nd); + mnt->mnt_namespace = NULL; spin_unlock(&vfsmount_lock); path_release(&old_nd); }
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 21 lines · Björn Steinbrink
Hi,
this[1] patch changed
check_mnt()so that mounting on a floating mount (i.e. one that was unmounted usingMNT_DETACHand was still in use) is possible, since we no longer check if the mountpoint is actually reachable. The problem is that we may lose any reference to the floating mount, but the mount on it will keep it alive, thus it will never go away. The following patch removes the reference from the mount to its namespace when it is unmounted lazily, so thatcheck_mntprotects from such mounts.Please CC me as I'm not subscribed to the list.
Bjoern
[1] http://lwn.net/Articles/91946/
diff -uNr --minimal
a/fs/namespace.cb/fs/namespace.c
fs/namespace.c 2004-11-06 04:38:37.299013810 +0100
Quoted 8 lines
fs/namespace.c 2004-11-06 04:38:37.299013810 +0100 renamed from fs/namespace.c 2004-10-31 00:41:02.000000000 +0200 +1
-1@@ -358,6 +358,7 @@ } else { struct nameidata old_nd; detach_mnt(mnt, &old_nd); + mnt->mnt_namespace = NULL; spin_unlock(&vfsmount_lock); path_release(&old_nd); } -
I don't think this patch clears mnt_namespace for the root of the umounted tree. How about this?
- --
Mike Waychison
Sun Microsystems, Inc.
1 (650) 352-5299 voice
1 (416) 202-8336 voice
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE: The opinions expressed in this email are held by me, and may not represent the views of Sun Microsystems, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBj5zKdQs4kOxk3/MRAv7FAKCdtASSH1sbq8KX1Yo0IrQZJ25q9gCfUp52 Uy0LxZvoqfJ9bh5jWGv7YM4=
=pce6
-----END PGP SIGNATURE-----
---
namespace.c | 1 + 1 files changed, 1 insertion(+)
fs/namespace.c +1 -0
@@ -352,6 +352,7 @@ void umount_tree(struct vfsmount *mnt) mnt = list_entry(kill.next, struct vfsmount, mnt_list);list_del_init (&mnt->mnt_list);list_del_init (&mnt->mnt_fslink); + mnt->mnt_namespace =NULL ;if (mnt->mnt_parent == mnt) {spin_unlock (&vfsmount_lock); }else {
Quoted 18 lines · On Mon, 08 Nov 2004 11:20:27 -0500 Mike Waychison <[email protected]>…
Quoted 17 lines · Björn Steinbrink
Hi,
this[1] patch changed
check_mnt()so that mounting on a floating mount(i.e. one that was unmounted usingMNT_DETACHand was still in use) is possible, since we no longer check if the mountpoint is actually reachable. The problem is that we may lose any reference to the floating mount, but the mount on it will keep it alive, thus it will never go away. The following patch removes the reference from the mount to its namespace when it is unmounted lazily, so thatcheck_mntprotects from such mounts.Please CC me as I'm not subscribed to the list.
Bjoern
Quoted 16 lines
fs/namespace.c 2004-11-06 04:38:37.299013810 +0100
Quoted 12 lines
diff -uNr --minimal
a/fs/namespace.cb/fs/namespace.cfs/namespace.c 2004-11-06 04:38:37.299013810 +0100 renamed from fs/namespace.c 2004-10-31 00:41:02.000000000 +0200 +1
-1@@ -358,6 +358,7 @@ } else { struct nameidata old_nd; detach_mnt(mnt, &old_nd); + mnt->mnt_namespace = NULL; spin_unlock(&vfsmount_lock); path_release(&old_nd); } -I don't think this patch clears
mnt_namespacefor the root of the umounted tree. How about this?
The root mount of the umounted tree is not detached yet, i.e. it has mnt->mnt_parent != mnt and is detached in the else-branch, so that is handled fine (at least my tests said so ;).
Only detached mounts and the namespace's root mount (that's the rootfs mount IIRC) have mnt->mnt_parent==mnt. And we have two cases here:
a) already detached mount, this cannot happen. The only possibility to get a detached mount into umount is the same we currently have with mount, some process kept a reference and used a relative path. But with the patch we would already bail out in check_mnt earlier in this case.
b) root mount, is not detached so all mounts are still reachable and can be unmounted as usual.
Please keep CC'ing me.
Bjoern
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 40 lines · Björn Steinbrink
Quoted 19 lines · On Mon, 08 Nov 2004 11:20:27 -0500 Mike Waychison <[email protected]>…
Quoted 17 lines · Björn Steinbrink
Hi,
this[1] patch changed
check_mnt()so that mounting on a floating mount(i.e. one that was unmounted usingMNT_DETACHand was still in use) is possible, since we no longer check if the mountpoint is actually reachable. The problem is that we may lose any reference to the floating mount, but the mount on it will keep it alive, thus it will never go away. The following patch removes the reference from the mount to its namespace when it is unmounted lazily, so thatcheck_mntprotects from such mounts.Please CC me as I'm not subscribed to the list.
Bjoern
Quoted 16 lines
fs/namespace.c 2004-11-06 04:38:37.299013810 +0100
Quoted 12 lines
diff -uNr --minimal
a/fs/namespace.cb/fs/namespace.cfs/namespace.c 2004-11-06 04:38:37.299013810 +0100 renamed from fs/namespace.c 2004-10-31 00:41:02.000000000 +0200 +1
-1@@ -358,6 +358,7 @@ } else { struct nameidata old_nd; detach_mnt(mnt, &old_nd); + mnt->mnt_namespace = NULL; spin_unlock(&vfsmount_lock); path_release(&old_nd); } -I don't think this patch clears
mnt_namespacefor the root of the umounted tree. How about this?
Quoted 13 lines
The root mount of the umounted tree is not detached yet, i.e. it has
mnt->mnt_parent!= mnt and is detached in the else-branch, so that is handled fine (at least my tests said so ;).
Only detached mounts and the namespace's root mount (that's the rootfs mount IIRC) have mnt->mnt_parent==mnt. And we have two cases here:
a) already detached mount, this cannot happen. The only possibility to get a detached mount into umount is the same we currently have with mount, some process kept a reference and used a relative path. But with the patch we would already bail out incheck_mntearlier in this case.
b) root mount, is not detached so all mounts are still reachable and can be unmounted as usual.
Yup. Okay, I got confused somewhere.
FWIW, the autofsng patchset I sent out a while ago I moved all the mnt_namespace accounting into attach_mnt and detach_mnt. It also allows detached mounts to be trees..
- --
Mike Waychison
Sun Microsystems, Inc.
1 (650) 352-5299 voice
1 (416) 202-8336 voice
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE: The opinions expressed in this email are held by me, and may not represent the views of Sun Microsystems, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBj7J7dQs4kOxk3/MRAj17AJ4ye0gtvg3YxwcKKT4pMoyAtIcnmQCeIKh/ g9i4P8m94gMFR5djT9G7wYg=
=htws
-----END PGP SIGNATURE-----