summaryrefslogtreecommitdiffstats
path: root/mm
diff options
context:
space:
mode:
authorAl Viro <viro@zeniv.linux.org.uk>2014-08-10 03:44:55 -0400
committerAl Viro <viro@zeniv.linux.org.uk>2014-08-11 12:28:10 -0400
commit12a5b5294cb1896e9a3c9fca8ff5a7e3def4e8c6 (patch)
tree9a3780d90c484e1a18e37b980d3d6cf2ac766711 /mm
parent60bb45297f7551833346c5cebc6d483ea17ea5f2 (diff)
downloadop-kernel-dev-12a5b5294cb1896e9a3c9fca8ff5a7e3def4e8c6.zip
op-kernel-dev-12a5b5294cb1896e9a3c9fca8ff5a7e3def4e8c6.tar.gz
fix copy_tree() regression
Since 3.14 we had copy_tree() get the shadowing wrong - if we had one vfsmount shadowing another (i.e. if A is a slave of B, C is mounted on A/foo, then D got mounted on B/foo creating D' on A/foo shadowed by C), copy_tree() of A would make a copy of D' shadow the the copy of C, not the other way around. It's easy to fix, fortunately - just make sure that mount follows the one that shadows it in mnt_child as well as in mnt_hash, and when copy_tree() decides to attach a new mount, check if the last child it has added to the same parent should be shadowing the new one. And if it should, just use the same logics commit_tree() has - put the new mount into the hash and children lists right after the one that should shadow it. Cc: stable@vger.kernel.org [3.14 and later] Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Diffstat (limited to 'mm')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud