From: Li Lingfeng <lilingfeng@huaweicloud.com>
To: dhowells@redhat.com, marc.dionne@auristor.com, raven@themaw.net,
gregkh@linuxfoundation.org, rafael@kernel.org,
viro@zeniv.linux.org.uk, brauner@kernel.org, jack@suse.cz,
miklos@szeredi.hu, trond.myklebust@hammerspace.com,
anna@kernel.org, sfrench@samba.org, pc@manguebit.com,
ronniesahlberg@gmail.com, sprasad@microsoft.com, tom@talpey.com,
bharathsm@microsoft.com, djwong@kernel.org
Cc: linux-afs@lists.infradead.org, linux-kernel@vger.kernel.org,
autofs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-nfs@vger.kernel.org, linux-cifs@vger.kernel.org,
samba-technical@lists.samba.org, yi.zhang@huawei.com,
yangerkun@huawei.com, zhangxiaoxu5@huawei.com,
lilingfeng3@huawei.com
Subject: Re: [PATCH RFC 2/2] NFSv4: set sb_flags to second superblock
Date: Fri, 14 Jun 2024 11:14:27 +0800 [thread overview]
Message-ID: <ca71d3c4-0b87-8a1e-a442-236d91674a87@huaweicloud.com> (raw)
In-Reply-To: <20240604112636.236517-3-lilingfeng@huaweicloud.com>
I think this may be a problem, but I'm unable to come up with a suitable
solution. Would you mind providing some suggestions?
在 2024/6/4 19:26, Li Lingfeng 写道:
> From: Li Lingfeng <lilingfeng3@huawei.com>
>
> During the process of mounting an NFSv4 client, two superblocks will be
> created in sequence. The first superblock corresponds to the root
> directory exported by the server, and the second superblock corresponds to
> the directory that will be actually mounted. The first superblock will
> eventually be destroyed.
> The flag passed from user mode will only be passed to the first
> superblock, resulting in the actual used superblock not carrying the flag
> passed from user mode(fs_context_for_submount() will set sb_flags as 0).
>
> If the 'ro' parameter is used in two consecutive mount commands, only the
> first execution will create a new vfsmount, and the kernel will return
> EBUSY on the second execution. However, if a remount command with the 'ro'
> parameter is executed between the two mount commands, both mount commands
> will create new vfsmounts.
>
> The superblock generated after the first mount command does not have the
> 'ro' flag, and the read-only status of the file system is implemented by
> checking the read-only flag of the vfsmount. After executing the remount
> command, the 'ro' flag will be added to the superblock. When the second
> mount command is executed, the comparison result between the superblock
> with the 'ro' flag and the fs_context without the flag in the
> nfs_compare_mount_options() function will be different, resulting in the
> creation of a new vfsmount.
>
> This problem can be reproduced by performing the following operations:
> mount -t nfs -o ro,vers=4.0 192.168.240.250:/sdb /mnt/sdb
> mount -t nfs -o remount,ro,vers=4.0 192.168.240.250:/sdb /mnt/sdb
> mount -t nfs -o ro,vers=4.0 192.168.240.250:/sdb /mnt/sdb
> Two vfsmounts are generated:
> [root@localhost ~]# mount | grep nfs
> 192.168.240.250:/sdb on /mnt/sdb type nfs4 (ro,relatime,vers=4.0,
> rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,
> sec=sys,clientaddr=192.168.240.251,local_lock=none,addr=192.168.240.250)
> 192.168.240.250:/sdb on /mnt/sdb type nfs4 (ro,relatime,vers=4.0,
> rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,
> sec=sys,clientaddr=192.168.240.251,local_lock=none,addr=192.168.240.250)
>
> Fix this by setting sb_flags to second superblock.
>
> Signed-off-by: Li Lingfeng <lilingfeng3@huawei.com>
> ---
> fs/nfs/namespace.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/nfs/namespace.c b/fs/nfs/namespace.c
> index 887aeacedebd..8b3d75af60d4 100644
> --- a/fs/nfs/namespace.c
> +++ b/fs/nfs/namespace.c
> @@ -158,7 +158,7 @@ struct vfsmount *nfs_d_automount(struct path *path, unsigned int sb_flags)
> /* Open a new filesystem context, transferring parameters from the
> * parent superblock, including the network namespace.
> */
> - fc = fs_context_for_submount(path->mnt->mnt_sb->s_type, path->dentry, 0);
> + fc = fs_context_for_submount(path->mnt->mnt_sb->s_type, path->dentry, sb_flags);
> if (IS_ERR(fc))
> return ERR_CAST(fc);
>
next prev parent reply other threads:[~2024-06-14 3:14 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-04 11:26 [PATCH RFC 0/2] NFSv4: set sb_flags to second superblock Li Lingfeng
2024-06-04 11:26 ` [PATCH RFC 1/2] fs: pass sb_flags to submount Li Lingfeng
2024-06-04 11:26 ` [PATCH RFC 2/2] NFSv4: set sb_flags to second superblock Li Lingfeng
2024-06-14 3:14 ` Li Lingfeng [this message]
2024-07-13 9:33 ` 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=ca71d3c4-0b87-8a1e-a442-236d91674a87@huaweicloud.com \
--to=lilingfeng@huaweicloud.com \
--cc=anna@kernel.org \
--cc=autofs@vger.kernel.org \
--cc=bharathsm@microsoft.com \
--cc=brauner@kernel.org \
--cc=dhowells@redhat.com \
--cc=djwong@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=jack@suse.cz \
--cc=lilingfeng3@huawei.com \
--cc=linux-afs@lists.infradead.org \
--cc=linux-cifs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=marc.dionne@auristor.com \
--cc=miklos@szeredi.hu \
--cc=pc@manguebit.com \
--cc=rafael@kernel.org \
--cc=raven@themaw.net \
--cc=ronniesahlberg@gmail.com \
--cc=samba-technical@lists.samba.org \
--cc=sfrench@samba.org \
--cc=sprasad@microsoft.com \
--cc=tom@talpey.com \
--cc=trond.myklebust@hammerspace.com \
--cc=viro@zeniv.linux.org.uk \
--cc=yangerkun@huawei.com \
--cc=yi.zhang@huawei.com \
--cc=zhangxiaoxu5@huawei.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;
as well as URLs for NNTP newsgroup(s).