linux-kernel - [GIT PULL] mnt namespace updates for v4.13-rc1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <87d19fhon6.fsf@xmission.com>
Date:   Tue, 04 Jul 2017 16:34:53 -0500
From:   ebiederm@...ssion.com (Eric W. Biederman)
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     <linux-kernel@...r.kernel.org>,
        Linux Containers <containers@...ts.linux-foundation.org>,
        <linux-fsdevel@...r.kernel.org>
Subject: [GIT PULL] mnt namespace updates for v4.13-rc1

Linus,

Please pull the for-linus branch from the git tree:

   git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git for-linus

   HEAD: 296990deb389c7da21c78030376ba244dc1badf5 mnt: Make propagate_umount less slow for overlapping mount propagation trees

A big break through came during this development cycle as a way was
found to maintain the existing umount -l semantics while allowing for
optimizations that improve the performance.  That is represented by the
first change in this series moving the reparenting of mounts into their
own pass.  This has allowed addressing the horrific performance of
umount -l on a carefully crafted tree of mounts with locks held (0.06s
vs 60s in my testing).   What allowed this was not changing where
umounts propagate to while propgating umounts.

The next change fixes the case where the order of the mount whose umount
are being progated visits a tree where the mounts are stacked upon each
other in another order.  This is weird but not hard to implement.

The final change takes advantage of the unchanging mount propgation tree
to skip parts of the mount propgation tree that have already been
visited.  Yielding a very nice speed up in the worst case.

There remains one outstanding question about the semantics of umount -l
that I am still discussiong with Ram Pai.  In practice that area of the
semantics was changed by 1064f874abc0 ("mnt: Tuck mounts under others
instead of creating shadow/side mounts.") and no regressions have been
reported.  Still I intend to finish talking that out with him to ensure
there is not something a more intense use of mount propagation in the
future will not cause to become significant.

Eric W. Biederman (3):
      mnt: In umount propagation reparent in a separate pass
      mnt: In propgate_umount handle visiting mounts in any order
      mnt: Make propagate_umount less slow for overlapping mount propagation trees

 fs/mount.h     |   1 +
 fs/namespace.c |   1 +
 fs/pnode.c     | 212 ++++++++++++++++++++++++++++++++++++++++++++-------------
 3 files changed, 165 insertions(+), 49 deletions(-)

Eric