From: Li Lingfeng <lilingfeng3@huawei.com>
To: <trondmy@kernel.org>, <anna@kernel.org>
Cc: <linux-nfs@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<ehagberg@janestreet.com>, <linux-nfs@dimebar.com>,
<yukuai1@huaweicloud.com>, <houtao1@huawei.com>,
<yi.zhang@huawei.com>, <yangerkun@huawei.com>,
<lilingfeng@huaweicloud.com>, <lilingfeng3@huawei.com>
Subject: [PATCH 2/2] nfs: ignore SB_RDONLY when remounting nfs
Date: Tue, 4 Mar 2025 21:05:33 +0800 [thread overview]
Message-ID: <20250304130533.549840-3-lilingfeng3@huawei.com> (raw)
In-Reply-To: <20250304130533.549840-1-lilingfeng3@huawei.com>
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 <lilingfeng3@huawei.com>
---
fs/nfs/super.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/fs/nfs/super.c b/fs/nfs/super.c
index 3e5528c2c822..8f50447eb5d0 100644
--- a/fs/nfs/super.c
+++ b/fs/nfs/super.c
@@ -1047,6 +1047,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.31.1
next prev parent reply other threads:[~2025-03-04 12:48 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-04 13:05 [PATCH 0/2] Ignore SB_RDONLY when mounting and remounting nfs Li Lingfeng
2025-03-04 13:05 ` [PATCH 1/2] nfs: clear SB_RDONLY before getting superblock Li Lingfeng
2025-03-04 16:22 ` Eric Hagberg
2025-03-04 13:05 ` Li Lingfeng [this message]
2025-04-09 11:39 ` [PATCH 0/2] Ignore SB_RDONLY when mounting and remounting nfs Li Lingfeng
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250304130533.549840-3-lilingfeng3@huawei.com \
--to=lilingfeng3@huawei.com \
--cc=anna@kernel.org \
--cc=ehagberg@janestreet.com \
--cc=houtao1@huawei.com \
--cc=lilingfeng@huaweicloud.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@dimebar.com \
--cc=linux-nfs@vger.kernel.org \
--cc=trondmy@kernel.org \
--cc=yangerkun@huawei.com \
--cc=yi.zhang@huawei.com \
--cc=yukuai1@huaweicloud.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox