[Devel] [PATCH RHEL10 COMMIT] ms/fix propagation graph breakage by MOVE_MOUNT_SET_GROUP move_mount(2)

[Konstantin Khorenko]

The commit is pushed to "branch-rh10-6.12.0-55.13.1.vz10.2.x-ovz" and will appear at git at bitbucket.org:openvz/vzkernel.git
after rh10-6.12.0-55.13.1.el10
------>
commit 51d73aa73a6c20af6ba5059eb1e606d5b60d90d5
Author: Al Viro <viro at 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 <brauner at kernel.org>
    mFixes: 9ffb14ef61ba ("move_mount: allow to add a mount into an existing group")
    Signed-off-by: Al Viro <viro at 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-87ae6b3b4a8e@virtuozzo.com/
    
    https://virtuozzo.atlassian.net/browse/VSTOR-108041
    (cherry picked from commit d8cc0362f918d020ca1340d7694f07062dc30f36)
    Signed-off-by: Pavel Tikhomirov <ptikhomirov at 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 8379fd053cd75..d29d070736254 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -3402,7 +3402,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;
 	}