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/
diff -uNr --minimal a/fs/namespace.c b/fs/namespace.c
--- a/fs/namespace.c 2004-10-31 00:41:02.000000000 +0200
+++ b/fs/namespace.c 2004-11-06 04:38:37.299013810 +0100
@@ -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);
}
On Mon, 08 Nov 2004 11:20:27 -0500
Mike Waychison <[email protected]> wrote:
> Bj?rn Steinbrink wrote:
> > 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/
> >
> > diff -uNr --minimal a/fs/namespace.c b/fs/namespace.c
> > --- a/fs/namespace.c 2004-10-31 00:41:02.000000000 +0200
> > +++ b/fs/namespace.c 2004-11-06 04:38:37.299013810 +0100
> > @@ -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?
>
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
Bj?rn Steinbrink wrote:
> 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/
>
> diff -uNr --minimal a/fs/namespace.c b/fs/namespace.c
> --- a/fs/namespace.c 2004-10-31 00:41:02.000000000 +0200
> +++ b/fs/namespace.c 2004-11-06 04:38:37.299013810 +0100
> @@ -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-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Bj?rn Steinbrink wrote:
> On Mon, 08 Nov 2004 11:20:27 -0500
> Mike Waychison <[email protected]> wrote:
>
>>Bj?rn Steinbrink wrote:
>>
>>>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/
>>>
>>>diff -uNr --minimal a/fs/namespace.c b/fs/namespace.c
>>>--- a/fs/namespace.c 2004-10-31 00:41:02.000000000 +0200
>>>+++ b/fs/namespace.c 2004-11-06 04:38:37.299013810 +0100
>>>@@ -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?
>>
>
>
> 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.
>
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-----