Skip to contentSkip to conversation

umount.2: Correct the description of MNT_DETACH

PATCH In review Eric W. Biederman 3 participants 9 messages Sep 30, 2014 – Feb 2, 2015 VFS

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 umount.2: Correct the description of MNT_DETACH

I recently realized that I had been reasoning improperly about what umount(MNT_DETACH) did based on an insufficient description in the umount.2 man page, that matched my intuition but not the implementation.

When there are no submounts MNT_DETACH is essentially harmless to applications. Where there are submounts MNT_DETACH changes what is visible to applications using the detach directories.

---
 man2/umount.2 | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)
man2/umount.2 +4 -3
index 5ff88152c738..aea39d8306fe 100644
@@ -66,9 +66,10 @@ This can cause data loss.
 (Only for NFS mounts.)
 .TP
 .BR MNT_DETACH " (since Linux 2.4.11)"
-Perform a lazy unmount: make the mount point unavailable for
-new accesses, and actually perform the unmount when the mount point
-ceases to be busy.
+Perform a lazy unmount: make the mount point unavailable for new
+accesses, immediately disconnect the filesystem and all filesystems
+mounted below it from each other and from the mount table, and
+actually perform the unmount when the mount point ceases to be busy.
 .TP
 .BR MNT_EXPIRE " (since Linux 2.6.8)"
 Mark the mount point as expired.
Signature · 1 line
1.9.1
#1 lore raw
Quoted 20 lines · Eric W. Biederman

I recently realized that I had been reasoning improperly about what umount(MNT_DETACH) did based on an insufficient description in the umount.2 man page, that matched my intuition but not the implementation.

When there are no submounts MNT_DETACH is essentially harmless to applications. Where there are submounts MNT_DETACH changes what is visible to applications using the detach directories.

---
 man2/umount.2 | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)
man2/umount.2 +0 -0
index 5ff88152c738..aea39d8306fe 100644

man2/umount.2 This can cause data loss. · line 72

Quoted 10 lines
man2/umount.2 +4 -3
@@ -66,9 +66,10 @@ This can cause data loss.
 (Only for NFS mounts.)
 .TP
 .BR MNT_DETACH " (since Linux 2.4.11)"
-Perform a lazy unmount: make the mount point unavailable for
-new accesses, and actually perform the unmount when the mount point
-ceases to be busy.
+Perform a lazy unmount: make the mount point unavailable for new
+accesses, immediately disconnect the filesystem and all filesystems
+mounted below it from each other and from the mount table, and
+actually perform the unmount when the mount point ceases to be busy.

Want to add something like:

MNT_DETACH on a shared mount will propagate unmount events to its peer group. That means that recursively bind mounting a shared mount and then unmounting that recursive bind mount will unmount all submounts of the original mount. This behavior can be avoided by remounting a directory with MS_REC | MS_PRIVATE before unmounting it.

--Andy

Quoted 6 lines
man2/umount.2 +0 -1
 .TP
 .BR MNT_EXPIRE " (since Linux 2.6.8)"
 Mark the mount point as expired.
--

1.9.1

Signature · 2 lines
Andy Lutomirski
AMA Capital Management, LLC
#2 lore raw
Quoted 35 lines · Andy Lutomirski
Quoted 20 lines · Eric W. Biederman

I recently realized that I had been reasoning improperly about what umount(MNT_DETACH) did based on an insufficient description in the umount.2 man page, that matched my intuition but not the implementation.

When there are no submounts MNT_DETACH is essentially harmless to applications. Where there are submounts MNT_DETACH changes what is visible to applications using the detach directories.

---
 man2/umount.2 | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)
man2/umount.2 +0 -0
index 5ff88152c738..aea39d8306fe 100644

man2/umount.2 This can cause data loss. · line 72

Quoted 10 lines
man2/umount.2 +4 -3
@@ -66,9 +66,10 @@ This can cause data loss.
 (Only for NFS mounts.)
 .TP
 .BR MNT_DETACH " (since Linux 2.4.11)"
-Perform a lazy unmount: make the mount point unavailable for
-new accesses, and actually perform the unmount when the mount point
-ceases to be busy.
+Perform a lazy unmount: make the mount point unavailable for new
+accesses, immediately disconnect the filesystem and all filesystems
+mounted below it from each other and from the mount table, and
+actually perform the unmount when the mount point ceases to be busy.

Want to add something like:

Quoted 5 lines

MNT_DETACH on a shared mount will propagate unmount events to its peer group. That means that recursively bind mounting a shared mount and then unmounting that recursive bind mount will unmount all submounts of the original mount. This behavior can be avoided by remounting a directory with MS_REC | MS_PRIVATE before unmounting it.

Make that any unmount on a shared mount that will propogate unmount events to it's peer group.

Eric

#3 lore raw
Quoted 37 lines · Eric W. Biederman
Quoted 35 lines · Andy Lutomirski
Quoted 20 lines · Eric W. Biederman

I recently realized that I had been reasoning improperly about what umount(MNT_DETACH) did based on an insufficient description in the umount.2 man page, that matched my intuition but not the implementation.

When there are no submounts MNT_DETACH is essentially harmless to applications. Where there are submounts MNT_DETACH changes what is visible to applications using the detach directories.

---
 man2/umount.2 | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)
man2/umount.2 +0 -0
index 5ff88152c738..aea39d8306fe 100644

man2/umount.2 This can cause data loss. · line 72

Quoted 10 lines
man2/umount.2 +4 -3
@@ -66,9 +66,10 @@ This can cause data loss.
 (Only for NFS mounts.)
 .TP
 .BR MNT_DETACH " (since Linux 2.4.11)"
-Perform a lazy unmount: make the mount point unavailable for
-new accesses, and actually perform the unmount when the mount point
-ceases to be busy.
+Perform a lazy unmount: make the mount point unavailable for new
+accesses, immediately disconnect the filesystem and all filesystems
+mounted below it from each other and from the mount table, and
+actually perform the unmount when the mount point ceases to be busy.

Want to add something like:

Quoted 8 lines
Quoted 5 lines

MNT_DETACH on a shared mount will propagate unmount events to its peer group. That means that recursively bind mounting a shared mount and then unmounting that recursive bind mount will unmount all submounts of the original mount. This behavior can be avoided by remounting a directory with MS_REC | MS_PRIVATE before unmounting it.

Make that any unmount on a shared mount that will propogate unmount events to it's peer group.

I don't understand your proposed edit. Can you type it out explicitly?

--Andy

Quoted 3 lines

Eric

Signature · 2 lines
Andy Lutomirski
AMA Capital Management, LLC
#4 lore raw

Hi Eric,

I'm still hoping for a revised patch from you in the light of Andy's comments and question.

Thanks,

Michael

Quoted 58 lines · Andy Lutomirski
Quoted 37 lines · Eric W. Biederman
Quoted 35 lines · Andy Lutomirski
Quoted 20 lines · Eric W. Biederman

I recently realized that I had been reasoning improperly about what umount(MNT_DETACH) did based on an insufficient description in the umount.2 man page, that matched my intuition but not the implementation.

When there are no submounts MNT_DETACH is essentially harmless to applications. Where there are submounts MNT_DETACH changes what is visible to applications using the detach directories.

---
 man2/umount.2 | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)
man2/umount.2 +0 -0
index 5ff88152c738..aea39d8306fe 100644

man2/umount.2 This can cause data loss. · line 72

Quoted 10 lines
man2/umount.2 +4 -3
@@ -66,9 +66,10 @@ This can cause data loss.
 (Only for NFS mounts.)
 .TP
 .BR MNT_DETACH " (since Linux 2.4.11)"
-Perform a lazy unmount: make the mount point unavailable for
-new accesses, and actually perform the unmount when the mount point
-ceases to be busy.
+Perform a lazy unmount: make the mount point unavailable for new
+accesses, immediately disconnect the filesystem and all filesystems
+mounted below it from each other and from the mount table, and
+actually perform the unmount when the mount point ceases to be busy.

Want to add something like:

Quoted 8 lines
Quoted 5 lines

MNT_DETACH on a shared mount will propagate unmount events to its peer group. That means that recursively bind mounting a shared mount and then unmounting that recursive bind mount will unmount all submounts of the original mount. This behavior can be avoided by remounting a directory with MS_REC | MS_PRIVATE before unmounting it.

Make that any unmount on a shared mount that will propogate unmount events to it's peer group.

I don't understand your proposed edit. Can you type it out explicitly?

--Andy

Quoted 3 lines

Eric

Signature · 3 lines
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
#5 lore raw
Quoted 4 lines · Michael Kerrisk (man-pages)

Hi Eric,

I'm still hoping for a revised patch from you in the light of Andy's comments and question.

Andy's concerns are orthogonal to my original patch, and actually have nothing to do with MNT_DETACH.

Which was my point but here I will send a second patch on top of my first patch to document the effect of shared mounts in umount.2

Eric

#6 lore raw

PATCH 1/1 umount.2: Document the effect of shared subtrees on umount

---
 man2/umount.2 | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)
man2/umount.2 +18 -0
index aea39d8306fe..a0120b2fc811 100644
@@ -97,6 +97,24 @@ Don't dereference
 if it is a symbolic link.
 This flag allows security problems to be avoided in set-user-ID-\fIroot\fP
 programs that allow unprivileged users to unmount filesystems.
+
+.P
+Shared mount points cause any mount activity on that mount point
+including umounts to be forwarded to every shared mount point in it's
+peer group and every slave mount of that peer group.  This means that
+umount of any peer in a set of shared mounts will cause all of it's
+peers to be unmounted and all of their slaves to be unmounted as well.
+
+This propogagtion of unmount activity can be particularly surprising
+on systems where every mount point is shared by default.  On such
+systems recursively bind mounting the root directory of the filesystem
+onto a subdirectory and then later unmounting that subdirectory with
+.BR MNT_DETACH
+will cause every mount in the mount namespace to be lazily unmounted.
+
+To ensure umount does not propagate the mount point may be
+remounted with MS_REC | MS_PRIVATE prior to umount being called.
+
 .SH RETURN VALUE
 On success, zero is returned.
 On error, \-1 is returned, and
Signature · 1 line
1.9.1
#7 lore raw

Re: [PATCH] umount.2: Document the effect of shared subtrees on umount

Quoted 2 lines · Eric W. Biederman

Thanks, Eric. Again, sorry for the delay. I've applied this patch.

Cheers,

Michael

Quoted 34 lines
---
 man2/umount.2 | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)
man2/umount.2 +18 -0
index aea39d8306fe..a0120b2fc811 100644
@@ -97,6 +97,24 @@ Don't dereference
 if it is a symbolic link.
 This flag allows security problems to be avoided in set-user-ID-\fIroot\fP
 programs that allow unprivileged users to unmount filesystems.
+
+.P
+Shared mount points cause any mount activity on that mount point
+including umounts to be forwarded to every shared mount point in it's
+peer group and every slave mount of that peer group.  This means that
+umount of any peer in a set of shared mounts will cause all of it's
+peers to be unmounted and all of their slaves to be unmounted as well.
+
+This propogagtion of unmount activity can be particularly surprising
+on systems where every mount point is shared by default.  On such
+systems recursively bind mounting the root directory of the filesystem
+onto a subdirectory and then later unmounting that subdirectory with
+.BR MNT_DETACH
+will cause every mount in the mount namespace to be lazily unmounted.
+
+To ensure umount does not propagate the mount point may be
+remounted with MS_REC | MS_PRIVATE prior to umount being called.
+
 .SH RETURN VALUE
 On success, zero is returned.
 On error, \-1 is returned, and
Signature · 3 lines
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
#8 lore raw
In reply to Eric W. Biederman
Quoted 9 lines · Eric W. Biederman

I recently realized that I had been reasoning improperly about what umount(MNT_DETACH) did based on an insufficient description in the umount.2 man page, that matched my intuition but not the implementation.

When there are no submounts MNT_DETACH is essentially harmless to applications. Where there are submounts MNT_DETACH changes what is visible to applications using the detach directories.

Thanks, Eric, and sorry for the delay. I've
applied this now.

Cheers,

Michael

Quoted 24 lines
---
 man2/umount.2 | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)
man2/umount.2 +4 -3
index 5ff88152c738..aea39d8306fe 100644
@@ -66,9 +66,10 @@ This can cause data loss.
 (Only for NFS mounts.)
 .TP
 .BR MNT_DETACH " (since Linux 2.4.11)"
-Perform a lazy unmount: make the mount point unavailable for
-new accesses, and actually perform the unmount when the mount point
-ceases to be busy.
+Perform a lazy unmount: make the mount point unavailable for new
+accesses, immediately disconnect the filesystem and all filesystems
+mounted below it from each other and from the mount table, and
+actually perform the unmount when the mount point ceases to be busy.
 .TP
 .BR MNT_EXPIRE " (since Linux 2.6.8)"
 Mark the mount point as expired.
Signature · 3 lines
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/