From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C5E807482; Mon, 23 Jun 2025 21:19:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1750713594; cv=none; b=W+ZUzvwWLd2Y27W712TgK8Qi0dRp02jhCaGvTdk7an/7f4cPP+Xe8IpGz/3rJzCxjpCmOaZkzs/Jmc5VT0YkgOF53rN9xUJ9HUTLMFs1Rsm12a4+IjQLsNqY0QNfqmb0+xku5W42wJ1TwSqxjHJ+bLKHQbulVgAE9IRgVnIIMkY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1750713594; c=relaxed/simple; bh=YViEm5A7eGaBFKqQBHnsRYgC56FbCyQHsHKqxrwm9uM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=sfbYsGm6crf9j4YhBOTadXyFsGAXw7n1mS3GoFGNcSGBsY8A3FRjGq3wyu/rpxF+tAzyhPp8LQQIW/Mkl34qG11/R0rH0NvOlFqnTNt9hGK4aTYsxv2KS4rCkY0HyZ9FSL1j+XUW3PjOEc4JSo4vH6rqNSLCvZEo2nFY2RDsY64= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=iryCWGcF; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="iryCWGcF" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5ED98C4CEEA; Mon, 23 Jun 2025 21:19:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1750713594; bh=YViEm5A7eGaBFKqQBHnsRYgC56FbCyQHsHKqxrwm9uM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=iryCWGcFHtOuBvOHEltk7IByKmtVpocqcl1f3v3ScovVL6Z0xPtZrNwBQ2koISbDl Zgc63LKQPHlndzII4e1z+Wrv9J5s9oLpQt+JWfuWJlG1HH0j2eeeQSZdiPwszJ5065 A9T2VznxKsDa6TUiHtrpyKlIcFbB4DcVXQBbMRfU= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Christian Brauner , Al Viro , Sasha Levin Subject: [PATCH 5.15 128/411] fix propagation graph breakage by MOVE_MOUNT_SET_GROUP move_mount(2) Date: Mon, 23 Jun 2025 15:04:32 +0200 Message-ID: <20250623130636.788800879@linuxfoundation.org> X-Mailer: git-send-email 2.50.0 In-Reply-To: <20250623130632.993849527@linuxfoundation.org> References: <20250623130632.993849527@linuxfoundation.org> User-Agent: quilt/0.68 X-stable: review X-Patchwork-Hint: ignore Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 5.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Al Viro [ Upstream commit d8cc0362f918d020ca1340d7694f07062dc30f36 ] 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 Fixes: 9ffb14ef61ba ("move_mount: allow to add a mount into an existing group") Signed-off-by: Al Viro Signed-off-by: Sasha Levin --- fs/namespace.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/namespace.c b/fs/namespace.c index a99a060e89316..76a1cf75457be 100644 --- a/fs/namespace.c +++ b/fs/namespace.c @@ -2765,7 +2765,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; } -- 2.39.5