diff --git a/man7/mount_namespaces.7 b/man7/mount_namespaces.7
index e462e4cf2..100c5d271 100644
--- a/man7/mount_namespaces.7
+++ b/man7/mount_namespaces.7
@@ -30,7 +30,7 @@ mount_namespaces \- overview of Linux mount namespaces
 For an overview of namespaces, see
 .BR namespaces (7).
 .PP
-Mount namespaces provide isolation of the list of mount points seen
+Mount namespaces provide isolation of the list of mounts seen
 by the processes in each namespace instance.
 Thus, the processes in each of the mount namespace instances
 will see distinct single-directory hierarchies.
@@ -56,24 +56,24 @@ with the
 .BR CLONE_NEWNS
 flag.
 When a new mount namespace is created,
-its mount point list is initialized as follows:
+its mount list is initialized as follows:
 .IP * 3
 If the namespace is created using
 .BR clone (2),
-the mount point list of the child's namespace is a copy
-of the mount point list in the parent's namespace.
+the mount list of the child's namespace is a copy
+of the mount list in the parent's namespace.
 .IP *
 If the namespace is created using
 .BR unshare (2),
-the mount point list of the new namespace is a copy of
-the mount point list in the caller's previous mount namespace.
+the mount list of the new namespace is a copy of
+the mount list in the caller's previous mount namespace.
 .PP
-Subsequent modifications to the mount point list
+Subsequent modifications to the mount list
 .RB ( mount (2)
 and
 .BR umount (2))
 in either mount namespace will not (by default) affect the
-mount point list seen in the other namespace
+mount list seen in the other namespace
 (but see the following discussion of shared subtrees).
 .\"
 .SH SHARED SUBTREES
@@ -92,31 +92,31 @@ between namespaces
 .IR "peer group"
 that are propagating events to one another).
 .PP
-Each mount point is marked (via
+Each mount is marked (via
 .BR mount (2))
 as having one of the following
 .IR "propagation types" :
 .TP
 .BR MS_SHARED
-This mount point shares events with members of a peer group.
-Mount and unmount events immediately under this mount point will propagate
-to the other mount points that are members of the peer group.
+This mount shares events with members of a peer group.
+Mount and unmount events immediately under this mount will propagate
+to the other mounts that are members of the peer group.
 .I Propagation
 here means that the same mount or unmount will automatically occur
-under all of the other mount points in the peer group.
+under all of the other mounts in the peer group.
 Conversely, mount and unmount events that take place under
-peer mount points will propagate to this mount point.
+peer mounts will propagate to this mount.
 .TP
 .BR MS_PRIVATE
-This mount point is private; it does not have a peer group.
-Mount and unmount events do not propagate into or out of this mount point.
+This mount is private; it does not have a peer group.
+Mount and unmount events do not propagate into or out of this mount.
 .TP
 .BR MS_SLAVE
-Mount and unmount events propagate into this mount point from
+Mount and unmount events propagate into this mount from
 a (master) shared peer group.
-Mount and unmount events under this mount point do not propagate to any peer.
+Mount and unmount events under this mount do not propagate to any peer.
 .IP
-Note that a mount point can be the slave of another peer group
+Note that a mount can be the slave of another peer group
 while at the same time sharing mount and unmount events
 with a peer group of which it is a member.
 (More precisely, one peer group can be the slave of another peer group.)
@@ -145,37 +145,37 @@ For a discussion of the propagation type assigned to a new mount,
 see NOTES.
 .PP
 The propagation type is a per-mount-point setting;
-some mount points may be marked as shared
-(with each shared mount point being a member of a distinct peer group),
+some mounts may be marked as shared
+(with each shared mount being a member of a distinct peer group),
 while others are private
 (or slaved or unbindable).
 .PP
 Note that a mount's propagation type determines whether
-mounts and unmounts of mount points
+mounts and unmounts of mounts
 .I "immediately under"
-the mount point are propagated.
+the mount are propagated.
 Thus, the propagation type does not affect propagation of events for
-grandchildren and further removed descendant mount points.
-What happens if the mount point itself is unmounted is determined by
+grandchildren and further removed descendant mounts.
+What happens if the mount itself is unmounted is determined by
 the propagation type that is in effect for the
 .I parent
-of the mount point.
+of the mount.
 .PP
 Members are added to a
 .IR "peer group"
-when a mount point is marked as shared and either:
+when a mount is marked as shared and either:
 .IP * 3
-the mount point is replicated during the creation of a new mount namespace; or
+the mount is replicated during the creation of a new mount namespace; or
 .IP *
-a new bind mount is created from the mount point.
+a new bind mount is created from the mount.
 .PP
-In both of these cases, the new mount point joins the peer group
-of which the existing mount point is a member.
+In both of these cases, the new mount joins the peer group
+of which the existing mount is a member.
 .PP
-A new peer group is also created when a child mount point is created under
-an existing mount point that is marked as shared.
-In this case, the new child mount point is also marked as shared and
-the resulting peer group consists of all the mount points
+A new peer group is also created when a child mount is created under
+an existing mount that is marked as shared.
+In this case, the new child mount is also marked as shared and
+the resulting peer group consists of all the mounts
 that are replicated under the peers of parent mount.
 .PP
 A mount ceases to be a member of a peer group when either
@@ -183,7 +183,7 @@ the mount is explicitly unmounted,
 or when the mount is implicitly unmounted because a mount namespace is removed
 (because it has no more member processes).
 .PP
-The propagation type of the mount points in a mount namespace
+The propagation type of the mounts in a mount namespace
 can be discovered via the "optional fields" exposed in
 .IR /proc/[pid]/mountinfo .
 (See
@@ -193,11 +193,11 @@ The following tags can appear in the optional fields
 for a record in that file:
 .TP
 .I shared:X
-This mount point is shared in peer group
+This mount is shared in peer group
 .IR X .
 Each peer group has a unique ID that is automatically
 generated by the kernel,
-and all mount points in the same peer group will show the same ID.
+and all mounts in the same peer group will show the same ID.
 (These IDs are assigned starting from the value 1,
 and may be recycled when a peer group ceases to have any members.)
 .TP
@@ -232,7 +232,7 @@ This is an unbindable mount.
 If none of the above tags is present, then this is a private mount.
 .SS MS_SHARED and MS_PRIVATE example
 Suppose that on a terminal in the initial mount namespace,
-we mark one mount point as shared and another as private,
+we mark one mount as shared and another as private,
 and then view the mounts in
 .IR /proc/self/mountinfo :
 .PP
@@ -255,7 +255,7 @@ is a shared mount in peer group 1, and that
 has no optional tags, indicating that it is a private mount.
 The first two fields in each record in this file are the unique
 ID for this mount, and the mount ID of the parent mount.
-We can further inspect this file to see that the parent mount point of
+We can further inspect this file to see that the parent mount of
 .IR /mntS
 and
 .IR /mntP
@@ -284,8 +284,8 @@ sh2# \fBcat /proc/self/mountinfo | grep \(aq/mnt\(aq | sed \(aqs/ \- .*//\(aq\fP
 .in
 .PP
 The new mount namespace received a copy of the initial mount namespace's
-mount points.
-These new mount points maintain the same propagation types,
+mounts.
+These new mounts maintain the same propagation types,
 but have unique mount IDs.
 (The
 .IR \-\-propagation\ unchanged
@@ -322,10 +322,10 @@ was created as shared (inheriting this setting from its parent mount) and
 was created as a private mount.
 .PP
 Returning to the first terminal and inspecting the set-up,
-we see that the new mount created under the shared mount point
+we see that the new mount created under the shared mount
 .IR /mntS
 propagated to its peer mount (in the initial mount namespace),
-but the new mount created under the private mount point
+but the new mount created under the private mount
 .IR /mntP
 did not propagate:
 .PP
@@ -339,7 +339,7 @@ sh1# \fBcat /proc/self/mountinfo | grep \(aq/mnt\(aq | sed \(aqs/ \- .*//\(aq\fP
 .in
 .\"
 .SS MS_SLAVE example
-Making a mount point a slave allows it to receive propagated
+Making a mount a slave allows it to receive propagated
 mount and unmount events from a master shared peer group,
 while preventing it from propagating events to that master.
 This is useful if we want to (say) receive a mount event when
@@ -349,7 +349,7 @@ but want to prevent mount and unmount events under the slave mount
 from having side effects in other namespaces.
 .PP
 We can demonstrate the effect of slaving by first marking
-two mount points as shared in the initial mount namespace:
+two mounts as shared in the initial mount namespace:
 .PP
 .in +4n
 .EX
@@ -362,7 +362,7 @@ sh1# \fBcat /proc/self/mountinfo | grep \(aq/mnt\(aq | sed \(aqs/ \- .*//\(aq\fP
 .in
 .PP
 On a second terminal,
-we create a new mount namespace and inspect the mount points:
+we create a new mount namespace and inspect the mounts:
 .PP
 .in +4n
 .EX
@@ -373,7 +373,7 @@ sh2# \fBcat /proc/self/mountinfo | grep \(aq/mnt\(aq | sed \(aqs/ \- .*//\(aq\fP
 .EE
 .in
 .PP
-In the new mount namespace, we then mark one of the mount points as a slave:
+In the new mount namespace, we then mark one of the mounts as a slave:
 .PP
 .in +4n
 .EX
@@ -403,7 +403,7 @@ sh2# \fBmount /dev/sda5 /mntY/b\fP
 .EE
 .in
 .PP
-When we inspect the state of the mount points in the new mount namespace,
+When we inspect the state of the mounts in the new mount namespace,
 we see that
 .IR /mntX/a
 was created as a new shared mount
@@ -439,7 +439,7 @@ sh1# \fBcat /proc/self/mountinfo | grep \(aq/mnt\(aq | sed \(aqs/ \- .*//\(aq\fP
 .EE
 .in
 .PP
-Now we create a new mount point under
+Now we create a new mount under
 .IR /mntY
 in the first shell:
 .PP
@@ -455,9 +455,9 @@ sh1# \fBcat /proc/self/mountinfo | grep \(aq/mnt\(aq | sed \(aqs/ \- .*//\(aq\fP
 .EE
 .in
 .PP
-When we examine the mount points in the second mount namespace,
+When we examine the mounts in the second mount namespace,
 we see that in this case the new mount has been propagated
-to the slave mount point,
+to the slave mount,
 and that the new mount is itself a slave mount (to peer group 4):
 .PP
 .in +4n
@@ -473,11 +473,11 @@ sh2# \fBcat /proc/self/mountinfo | grep \(aq/mnt\(aq | sed \(aqs/ \- .*//\(aq\fP
 .\"
 .SS MS_UNBINDABLE example
 One of the primary purposes of unbindable mounts is to avoid
-the "mount point explosion" problem when repeatedly performing bind mounts
-of a higher-level subtree at a lower-level mount point.
+the "mount explosion" problem when repeatedly performing bind mounts
+of a higher-level subtree at a lower-level mount.
 The problem is illustrated by the following shell session.
 .PP
-Suppose we have a system with the following mount points:
+Suppose we have a system with the following mounts:
 .PP
 .in +4n
 .EX
@@ -490,7 +490,7 @@ Suppose we have a system with the following mount points:
 .PP
 Suppose furthermore that we wish to recursively bind mount
 the root directory under several users' home directories.
-We do this for the first user, and inspect the mount points:
+We do this for the first user, and inspect the mounts:
 .PP
 .in +4n
 .EX
@@ -605,8 +605,8 @@ Now we create unbindable recursive bind mounts for the other two users:
 .EE
 .in
 .PP
-Upon examining the list of mount points,
-we see there has been no explosion of mount points,
+Upon examining the list of mounts,
+we see there has been no explosion of mounts,
 because the unbindable mounts were not replicated
 under each user's directory:
 .PP
@@ -632,7 +632,7 @@ under each user's directory:
 The following table shows the effect that applying a new propagation type
 (i.e.,
 .IR "mount \-\-make\-xxxx")
-has on the existing propagation type of a mount point.
+has on the existing propagation type of a mount.
 The rows correspond to existing propagation types,
 and the columns are the new propagation settings.
 For reasons of space, "private" is abbreviated as "priv" and
@@ -667,9 +667,9 @@ mount \-\-bind A/a B/b
 .PP
 Here,
 .I A
-is the source mount point,
+is the source mount,
 .I B
-is the destination mount point,
+is the destination mount,
 .I a
 is a subdirectory path under the mount point
 .IR A ,
@@ -679,7 +679,7 @@ is a subdirectory path under the mount point
 .IR B .
 The propagation type of the resulting mount,
 .IR B/b ,
-depends on the propagation types of the mount points
+depends on the propagation types of the mounts
 .IR A
 and
 .IR B ,
@@ -715,15 +715,15 @@ mount \-\-move A B/b
 .PP
 Here,
 .I A
-is the source mount point,
+is the source mount,
 .I B
-is the destination mount point, and
+is the destination mount, and
 .I b
 is a subdirectory path under the mount point
 .IR B .
 The propagation type of the resulting mount,
 .IR B/b ,
-depends on the propagation types of the mount points
+depends on the propagation types of the mounts
 .IR A
 and
 .IR B ,
@@ -747,7 +747,7 @@ For further details, see
 in the kernel source tree.
 .\"
 .SS Mount semantics
-Suppose that we use the following command to create a mount point:
+Suppose that we use the following command to create a mount:
 .PP
 .in +4n
 .EX
@@ -757,7 +757,7 @@ mount device B/b
 .PP
 Here,
 .I B
-is the destination mount point, and
+is the destination mount, and
 .I b
 is a subdirectory path under the mount point
 .IR B .
@@ -768,7 +768,7 @@ where the propagation type of the source mount
 is considered always to be private.
 .\"
 .SS Unmount semantics
-Suppose that we use the following command to tear down a mount point:
+Suppose that we use the following command to tear down a mount:
 .PP
 .in +4n
 .EX
@@ -778,7 +778,7 @@ unmount A
 .PP
 Here,
 .I A
-is a mount point on
+is a mount on
 .IR B/b ,
 where
 .I B
@@ -871,7 +871,7 @@ onto
 .EE
 .in
 .PP
-Initially, these two mount points are in the same peer group,
+Initially, these two mounts are in the same peer group,
 but we then make the
 .IR /tmp/etc
 a slave of
@@ -896,7 +896,7 @@ Then we bind mount
 .IR /tmp/etc
 onto
 .IR /mnt/tmp/etc .
-Again, the two mount points are initially in the same peer group,
+Again, the two mounts are initially in the same peer group,
 but we then make
 .IR /mnt/tmp/etc
 a slave of
@@ -965,9 +965,9 @@ Mount namespaces first appeared in Linux 2.4.19.
 Namespaces are a Linux-specific feature.
 .\"
 .SH NOTES
-The propagation type assigned to a new mount point depends
+The propagation type assigned to a new mount depends
 on the propagation type of the parent mount.
-If the mount point has a parent (i.e., it is a non-root mount
+If the mount has a parent (i.e., it is a non-root mount
 point) and the propagation type of the parent is
 .BR MS_SHARED ,
 then the propagation type of the new mount is also
@@ -976,13 +976,13 @@ Otherwise, the propagation type of the new mount is
 .BR MS_PRIVATE .
 .PP
 Notwithstanding the fact that the default propagation type
-for new mount points is in many cases
+for new mount is in many cases
 .BR MS_PRIVATE ,
 .BR MS_SHARED
 is typically more useful.
 For this reason,
 .BR systemd (1)
-automatically remounts all mount points as
+automatically remounts all mounts as
 .BR MS_SHARED
 on system startup.
 Thus, on most modern systems, the default propagation type is in practice
@@ -991,14 +991,14 @@ Thus, on most modern systems, the default propagation type is in practice
 Since, when one uses
 .BR unshare (1)
 to create a mount namespace,
-the goal is commonly to provide full isolation of the mount points
+the goal is commonly to provide full isolation of the mounts
 in the new namespace,
 .BR unshare (1)
 (since
 .IR util\-linux
 version 2.27) in turn reverses the step performed by
 .BR systemd (1),
-by making all mount points private in the new namespace.
+by making all mounts private in the new namespace.
 That is,
 .BR unshare (1)
 performs the equivalent of the following in the new mount namespace:
@@ -1022,7 +1022,7 @@ may desire to prevent propagation of mount events to other mount namespaces
 (as is done by
 .BR unshare (1)).
 This can be done by changing the propagation type of
-mount points in the new namespace to either
+mounts in the new namespace to either
 .B MS_SLAVE
 or
 .BR MS_PRIVATE ,
@@ -1048,9 +1048,9 @@ Note the following points with respect to mount namespaces:
 .IP * 3
 Each mount namespace has an owner user namespace.
 As explained above, when a new mount namespace is created,
-its mount point list is initialized as a copy of the mount point list
+its mount list is initialized as a copy of the mount list
 of another mount namespace.
-If the new namespace and the namespace from which the mount point list
+If the new namespace and the namespace from which the mount list
 was copied are owned by different user namespaces,
 then the new mount namespace is considered
 .IR "less privileged" .
@@ -1139,7 +1139,7 @@ In the new mount namespace,
 the propagation type of all mounts is set to private.
 We then create a shared bind mount at
 .IR /mnt ,
-and a small hierarchy of mount points underneath that mount point.
+and a small hierarchy of mounts underneath that mount.
 .IP
 .in +4n
 .EX
@@ -1162,7 +1162,7 @@ ns1# \fBgrep /mnt /proc/self/mountinfo | sed \(aqs/ \- .*//\(aq\fP
 Continuing in the same shell session,
 we then create a second shell in a new user namespace and a new
 (less privileged) mount namespace and
-check the state of the propagated mount points rooted at
+check the state of the propagated mounts rooted at
 .IR /mnt .
 .IP
 .in +4n
@@ -1176,7 +1176,7 @@ ns2# \fBgrep /mnt /proc/self/mountinfo | sed \(aqs/ \- .*//\(aq\fP
 .EE
 .in
 .IP
-Of note in the above output is that the propagation type of the mount point
+Of note in the above output is that the propagation type of the mount
 .I /mnt
 has been reduced to slave, as explained near the start of this subsection.
 This means that submount events will propagate from the master