1. 03 Apr, 2015 8 commits
    • Eric W. Biederman's avatar
      mnt: Don't propagate unmounts to locked mounts · 0c56fe31
      Eric W. Biederman authored
      If the first mount in shared subtree is locked don't unmount the
      shared subtree.
      
      This is ensured by walking through the mounts parents before children
      and marking a mount as unmountable if it is not locked or it is locked
      but it's parent is marked.
      
      This allows recursive mount detach to propagate through a set of
      mounts when unmounting them would not reveal what is under any locked
      mount.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      0c56fe31
    • Eric W. Biederman's avatar
      mnt: On an unmount propagate clearing of MNT_LOCKED · 5d88457e
      Eric W. Biederman authored
      A prerequisite of calling umount_tree is that the point where the tree
      is mounted at is valid to unmount.
      
      If we are propagating the effect of the unmount clear MNT_LOCKED in
      every instance where the same filesystem is mounted on the same
      mountpoint in the mount tree, as we know (by virtue of the fact
      that umount_tree was called) that it is safe to reveal what
      is at that mountpoint.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      5d88457e
    • Eric W. Biederman's avatar
      mnt: Delay removal from the mount hash. · 411a938b
      Eric W. Biederman authored
      - Modify __lookup_mnt_hash_last to ignore mounts that have MNT_UMOUNTED set.
      - Don't remove mounts from the mount hash table in propogate_umount
      - Don't remove mounts from the mount hash table in umount_tree before
        the entire list of mounts to be umounted is selected.
      - Remove mounts from the mount hash table as the last thing that
        happens in the case where a mount has a parent in umount_tree.
        Mounts without parents are not hashed (by definition).
      
      This paves the way for delaying removal from the mount hash table even
      farther and fixing the MNT_LOCKED vs MNT_DETACH issue.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      411a938b
    • Eric W. Biederman's avatar
      mnt: Add MNT_UMOUNT flag · 590ce4bc
      Eric W. Biederman authored
      In some instances it is necessary to know if the the unmounting
      process has begun on a mount.  Add MNT_UMOUNT to make that reliably
      testable.
      
      This fix gets used in fixing locked mounts in MNT_DETACH
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      590ce4bc
    • Eric W. Biederman's avatar
      mnt: In umount_tree reuse mnt_list instead of mnt_hash · c003b26f
      Eric W. Biederman authored
      umount_tree builds a list of mounts that need to be unmounted.
      Utilize mnt_list for this purpose instead of mnt_hash.  This begins to
      allow keeping a mount on the mnt_hash after it is unmounted, which is
      necessary for a properly functioning MNT_LOCKED implementation.
      
      The fact that mnt_list is an ordinary list makding available list_move
      is nice bonus.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      c003b26f
    • Eric W. Biederman's avatar
      mnt: Don't propagate umounts in __detach_mounts · 8318e667
      Eric W. Biederman authored
      Invoking mount propagation from __detach_mounts is inefficient and
      wrong.
      
      It is inefficient because __detach_mounts already walks the list of
      mounts that where something needs to be done, and mount propagation
      walks some subset of those mounts again.
      
      It is actively wrong because if the dentry that is passed to
      __detach_mounts is not part of the path to a mount that mount should
      not be affected.
      
      change_mnt_propagation(p,MS_PRIVATE) modifies the mount propagation
      tree of a master mount so it's slaves are connected to another master
      if possible.  Which means even removing a mount from the middle of a
      mount tree with __detach_mounts will not deprive any mount propagated
      mount events.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      8318e667
    • Eric W. Biederman's avatar
      mnt: Improve the umount_tree flags · e819f152
      Eric W. Biederman authored
      - Remove the unneeded declaration from pnode.h
      - Mark umount_tree static as it has no callers outside of namespace.c
      - Define an enumeration of umount_tree's flags.
      - Pass umount_tree's flags in by name
      
      This removes the magic numbers 0, 1 and 2 making the code a little
      clearer and makes it possible for there to be lazy unmounts that don't
      propagate.  Which is what __detach_mounts actually wants for example.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      e819f152
    • Eric W. Biederman's avatar
      mnt: Use hlist_move_list in namespace_unlock · a3b3c562
      Eric W. Biederman authored
      Small cleanup to make the code more readable and maintainable.
      Signed-off-by: default avatarEric Biederman <ebiederm@xmission.com>
      a3b3c562
  2. 29 Mar, 2015 7 commits
  3. 28 Mar, 2015 9 commits
  4. 27 Mar, 2015 6 commits
  5. 26 Mar, 2015 10 commits