The commit is pushed to "branch-rh7-3.10.0-1160.129.1.vz7.226.x-ovz" and will
appear at g...@bitbucket.org:openvz/vzkernel.git
after rh7-3.10.0-1160.129.1.vz7.226.1
------>
commit e2d91869ad03b0671493abb67d72f6168b5c6ffc
Author: Al Viro <v...@zeniv.linux.org.uk>
Date: Mon Jul 28 12:32:30 2025 +0800
ms/fix propagation graph breakage by MOVE_MOUNT_SET_GROUP move_mount(2)
9ffb14ef61ba "move_mount: allow to add a mount into an existing group"
breaks assertions on ->mnt_share/->mnt_slave. For once, the data structures
in question are actually documented.
Documentation/filesystem/sharedsubtree.rst:
All vfsmounts in a peer group have the same ->mnt_master. If it is
non-NULL, they form a contiguous (ordered) segment of slave list.
do_set_group() puts a mount into the same place in propagation graph
as the old one. As the result, if old mount gets events from somewhere
and is not a pure event sink, new one needs to be placed next to the
old one in the slave list the old one's on. If it is a pure event
sink, we only need to make sure the new one doesn't end up in the
middle of some peer group.
"move_mount: allow to add a mount into an existing group" ends up putting
the new one in the beginning of list; that's definitely not going to be
in the middle of anything, so that's fine for case when old is not marked
shared. In case when old one _is_ marked shared (i.e. is not a pure event
sink), that breaks the assumptions of propagation graph iterators.
Put the new mount next to the old one on the list - that does the right
thing
in "old is marked shared" case and is just as correct as the current
behaviour
if old is not marked shared (kudos to Pavel for pointing that out - my
original
suggested fix changed behaviour in the "nor marked" case, which complicated
things for no good reason).
Reviewed-by: Christian Brauner <brau...@kernel.org>
mFixes: 9ffb14ef61ba ("move_mount: allow to add a mount into an existing
group")
Signed-off-by: Al Viro <v...@zeniv.linux.org.uk>
As CRIU is heavily using this feature it can accidentally break mount
propagation after container migration (leading e.g. to multiple
duplicate mount creation). See one example breakage scenario here in
original bug discussion comments:
https://lore.kernel.org/all/2c1ebff3-c840-4f68-84a6-87ae6b3b4...@virtuozzo.com/
https://virtuozzo.atlassian.net/browse/VSTOR-108041
(cherry picked from commit d8cc0362f918d020ca1340d7694f07062dc30f36)
Signed-off-by: Pavel Tikhomirov <ptikhomi...@virtuozzo.com>
Feature: fix ms/fs
---
fs/namespace.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/namespace.c b/fs/namespace.c
index 6e89af4a66a0..2c9e75b7a467 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -3153,7 +3153,7 @@ static int do_set_group(struct path *from_path, struct
path *to_path)
if (IS_MNT_SLAVE(from)) {
struct mount *m = from->mnt_master;
- list_add(&to->mnt_slave, &m->mnt_slave_list);
+ list_add(&to->mnt_slave, &from->mnt_slave);
to->mnt_master = m;
}
_______________________________________________
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel
