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 B7E5B16419; Mon, 23 Jun 2025 13:39:51 +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=1750685991; cv=none; b=kpMRbbWK/0u7wfwtc/ClrQM3wF2gNQLSb4qWkmPGQbZibQBUGVV21ftQfsMXceyBRhi5NOMiwJ8uNdxARrWY0VoSajLiwzT/ckAfdsmdqzf/GCOkxzttNLhASUeaD7lP5Ao6KxqjNyq5horYi0BT5VwIjQ3RQ/DmT5VbsXumh8I= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1750685991; c=relaxed/simple; bh=IjMzSt29O6DfBb2H9LPLDe9LTf9XAyPLXaArA6TqpT4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=RZ69hY3aMVKBRbeF4l1wS72LQ5Bblr5C4zyyFsvtnQoQVyav99P1i2tksee6wcaIqkMZ6Tt2/GFr7bD+hiko1Qh4/LhmQWFkJjqz0VSklrgS+VB3wkJSQDDzWV2cmkUuvWgy+BpTB1eAzxXkjlswPiEf4M6TQRc4XxNNTaRElNE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=stWsfRGV; 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="stWsfRGV" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4B4E7C4CEEA; Mon, 23 Jun 2025 13:39:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1750685991; bh=IjMzSt29O6DfBb2H9LPLDe9LTf9XAyPLXaArA6TqpT4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=stWsfRGVCYE5MLbU/R+0+nS63WWwhcXZul3gmfXdOxAmyDGDfd7otgelH1gTqGbSc mIiuaeg3LMXWWN6Zg5vHBv9mIx6wM28MD7byD4pNJqqrLNa3frXR/R+GFKIURSeYbf 3rDIkHP0ecG+MsS4+PRYO5u+gL8D73fmpSFbcv1I= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Li Lingfeng , Anna Schumaker , Sasha Levin Subject: [PATCH 5.10 084/355] nfs: ignore SB_RDONLY when remounting nfs Date: Mon, 23 Jun 2025 15:04:45 +0200 Message-ID: <20250623130629.333763193@linuxfoundation.org> X-Mailer: git-send-email 2.50.0 In-Reply-To: <20250623130626.716971725@linuxfoundation.org> References: <20250623130626.716971725@linuxfoundation.org> User-Agent: quilt/0.68 X-stable: review X-Patchwork-Hint: ignore Precedence: bulk X-Mailing-List: patches@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 5.10-stable review patch. If anyone has any objections, please let me know. ------------------ From: Li Lingfeng [ Upstream commit 80c4de6ab44c14e910117a02f2f8241ffc6ec54a ] In some scenarios, when mounting NFS, more than one superblock may be created. The final superblock used is the last one created, but only the first superblock carries the ro flag passed from user space. If a ro flag is added to the superblock via remount, it will trigger the issue described in Link[1]. Link[2] attempted to address this by marking the superblock as ro during the initial mount. However, this introduced a new problem in scenarios where multiple mount points share the same superblock: [root@a ~]# mount /dev/sdb /mnt/sdb [root@a ~]# echo "/mnt/sdb *(rw,no_root_squash)" > /etc/exports [root@a ~]# echo "/mnt/sdb/test_dir2 *(ro,no_root_squash)" >> /etc/exports [root@a ~]# systemctl restart nfs-server [root@a ~]# mount -t nfs -o rw 127.0.0.1:/mnt/sdb/test_dir1 /mnt/test_mp1 [root@a ~]# mount | grep nfs4 127.0.0.1:/mnt/sdb/test_dir1 on /mnt/test_mp1 type nfs4 (rw,relatime,... [root@a ~]# mount -t nfs -o ro 127.0.0.1:/mnt/sdb/test_dir2 /mnt/test_mp2 [root@a ~]# mount | grep nfs4 127.0.0.1:/mnt/sdb/test_dir1 on /mnt/test_mp1 type nfs4 (ro,relatime,... 127.0.0.1:/mnt/sdb/test_dir2 on /mnt/test_mp2 type nfs4 (ro,relatime,... [root@a ~]# When mounting the second NFS, the shared superblock is marked as ro, causing the previous NFS mount to become read-only. To resolve both issues, the ro flag is no longer applied to the superblock during remount. Instead, the ro flag on the mount is used to control whether the mount point is read-only. Fixes: 281cad46b34d ("NFS: Create a submount rpc_op") Link[1]: https://lore.kernel.org/all/20240604112636.236517-3-lilingfeng@huaweicloud.com/ Link[2]: https://lore.kernel.org/all/20241130035818.1459775-1-lilingfeng3@huawei.com/ Signed-off-by: Li Lingfeng Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin --- fs/nfs/super.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/fs/nfs/super.c b/fs/nfs/super.c index 27923c2b36f77..7c58a1688f7f7 100644 --- a/fs/nfs/super.c +++ b/fs/nfs/super.c @@ -1000,6 +1000,16 @@ int nfs_reconfigure(struct fs_context *fc) sync_filesystem(sb); + /* + * The SB_RDONLY flag has been removed from the superblock during + * mounts to prevent interference between different filesystems. + * Similarly, it is also necessary to ignore the SB_RDONLY flag + * during reconfiguration; otherwise, it may also result in the + * creation of redundant superblocks when mounting a directory with + * different rw and ro flags multiple times. + */ + fc->sb_flags_mask &= ~SB_RDONLY; + /* * Userspace mount programs that send binary options generally send * them populated with default values. We have no way to know which -- 2.39.5