Re: [PATCH 4/4] fix IS_MNT_PROPAGATING uses

[Christian Brauner <brauner@kernel.org>]

On Thu, May 08, 2025 at 09:02:42PM +0100, Al Viro wrote:
> propagate_mnt() does not attach anything to mounts created during
> propagate_mnt() itself.  What's more, anything on ->mnt_slave_list
> of such new mount must also be new, so we don't need to even look
> there.
> 
> When move_mount() had been introduced, we've got an additional
> class of mounts to skip - if we are moving from anon namespace,
> we do not want to propagate to mounts we are moving (i.e. all
> mounts in that anon namespace).
> 
> Unfortunately, the part about "everything on their ->mnt_slave_list
> will also be ignorable" is not true - if we have propagation graph
> 	A -> B -> C
> and do OPEN_TREE_CLONE open_tree() of B, we get
> 	A -> [B <-> B'] -> C
> as propagation graph, where B' is a clone of B in our detached tree.
> Making B private will result in
> 	A -> B' -> C
> C still gets propagation from A, as it would after making B private
> if we hadn't done that open_tree(), but now the propagation goes
> through B'.  Trying to move_mount() our detached tree on subdirectory
> in A should have
> 	* moved B' on that subdirectory in A
> 	* skipped the corresponding subdirectory in B' itself
> 	* copied B' on the corresponding subdirectory in C.
> As it is, the logics in propagation_next() and friends ends up
> skipping propagation into C, since it doesn't consider anything
> downstream of B'.
> 
> IOW, walking the propagation graph should only skip the ->mnt_slave_list
> of new mounts; the only places where the check for "in that one
> anon namespace" are applicable are propagate_one() (where we should
> treat that as the same kind of thing as "mountpoint we are looking
> at is not visible in the mount we are looking at") and
> propagation_would_overmount().  The latter is better dealt with
> in the caller (can_move_mount_beneath()); on the first call of
> propagation_would_overmount() the test is always false, on the
> second it is always true in "move from anon namespace" case and
> always false in "move within our namespace" one, so it's easier
> to just use check_mnt() before bothering with the second call and
> be done with that.
> 
> Fixes: 064fe6e233e8 ("mount: handle mount propagation for detached mount trees")
> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
> ---

Thanks, looks good.
Reviewed-by: Christian Brauner <brauner@kernel.org>