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>, <yukuai1@huaweicloud.com>,
<houtao1@huawei.com>, <yi.zhang@huawei.com>,
<yangerkun@huawei.com>, <lilingfeng@huaweicloud.com>
Subject: Re: [PATCH] nfs: remove SB_RDONLY when remounting nfs
Date: Mon, 3 Mar 2025 09:08:51 +0800 [thread overview]
Message-ID: <95a2cb76-bade-47e0-a6fb-e22d50c13501@huawei.com> (raw)
In-Reply-To: <20250221082613.2674633-1-lilingfeng3@huawei.com>
Friendly ping.
Thanks.
在 2025/2/21 16:26, Li Lingfeng 写道:
> 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 | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/fs/nfs/super.c b/fs/nfs/super.c
> index aeb715b4a690..f08e1d7fb179 100644
> --- a/fs/nfs/super.c
> +++ b/fs/nfs/super.c
> @@ -1047,6 +1047,7 @@ int nfs_reconfigure(struct fs_context *fc)
>
> sync_filesystem(sb);
>
> + fc->sb_flags &= ~SB_RDONLY;
> /*
> * Userspace mount programs that send binary options generally send
> * them populated with default values. We have no way to know which
next prev parent reply other threads:[~2025-03-03 1:09 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-21 8:26 [PATCH] nfs: remove SB_RDONLY when remounting nfs Li Lingfeng
2025-03-03 1:08 ` Li Lingfeng [this message]
2025-03-03 3:33 ` Zhang Yi
2025-03-03 12:58 ` 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=95a2cb76-bade-47e0-a6fb-e22d50c13501@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@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