Re: [PATCH 0/6] Fix up NFS client mount option regressions

[Trond Myklebust <trondmy@kernel.org>]

On Fri, 2026-01-30 at 10:41 +0800, Li Lingfeng wrote:
> Hi Trond,
> 
> 在 2026/1/30 9:43, Trond Myklebust 写道:
> > On Fri, 2026-01-30 at 09:34 +0800, Li Lingfeng wrote:
> > > Hi Trond,
> > > 
> > > 在 2026/1/30 0:00, Trond Myklebust 写道:
> > > > On Thu, 2026-01-29 at 15:06 +0800, Li Lingfeng wrote:
> > > > > Hi Trond,
> > > > > 
> > > > > 在 2025/11/29 12:06, Trond Myklebust 写道:
> > > > > > From: Trond Myklebust <trond.myklebust@hammerspace.com>
> > > > > > 
> > > > > > The recent changes to suppress the 'ro' and 'rw' mount
> > > > > > options
> > > > > > when
> > > > > > mounting the same NFS filesystem with different settings
> > > > > > are
> > > > > > causing
> > > > > > confusion with users, and are an unnecessary restriction.
> > > > > > They
> > > > > > represent
> > > > > > a functionality regression.
> > > > > > 
> > > > > > The following patch set reverts the regressions, before
> > > > > > applying a
> > > > > > different set of fixes to address the original problem,
> > > > > > which
> > > > > > was
> > > > > > one of
> > > > > > the NFSv4 mount automounter code failing to propagate the
> > > > > > correct
> > > > > > mount
> > > > > > options.
> > > > > > 
> > > > > > Trond Myklebust (6):
> > > > > >      Revert "nfs: ignore SB_RDONLY when remounting nfs"
> > > > > >      Revert "nfs: clear SB_RDONLY before getting
> > > > > > superblock"
> > > > > >      Revert "nfs: ignore SB_RDONLY when mounting nfs"
> > > > > >      NFS: Automounted filesystem should inherit
> > > > > > ro,noexec,nodev,sync
> > > > > > flags
> > > > > >      NFS: Fix inheritance of the block sizes when
> > > > > > automounting
> > > > > >      NFS: Fix up the automount fs_context to use the
> > > > > > correct
> > > > > > cred
> > > > > > 
> > > > > >     fs/nfs/client.c           | 21 +++++++++++++++++----
> > > > > >     fs/nfs/internal.h         |  3 +--
> > > > > >     fs/nfs/namespace.c        | 16 +++++++++++++++-
> > > > > >     fs/nfs/nfs4client.c       | 18 ++++++++++++++----
> > > > > >     fs/nfs/super.c            | 33 +++---------------------
> > > > > > -----
> > > > > > ----
> > > > > >     include/linux/nfs_fs_sb.h |  5 +++++
> > > > > >     6 files changed, 55 insertions(+), 41 deletions(-)
> > > > > After this series of patches was merged, I found that the
> > > > > issue
> > > > > described
> > > > > in link [1] has appeared again.
> > > > > 
> > > > > [root@nfs-client1 ~]# mount /dev/sda /mnt2
> > > > > [root@nfs-client1 ~]# echo "/mnt2
> > > > > *(rw,no_root_squash,fsid=0)"
> > > > > > /etc/exports
> > > > > [root@nfs-client1 ~]# systemctl restart nfs-server
> > > > > [root@nfs-client1 ~]# mount -t nfs -o ro,vers=4 127.0.0.1:/
> > > > > /mnt/sdaa
> > > > > [root@nfs-client1 ~]# mount -t nfs -o rw,vers=4 127.0.0.1:/
> > > > > /mnt/sdaa
> > > > > [root@nfs-client1 ~]# mount -t nfs -o ro,vers=4 127.0.0.1:/
> > > > > /mnt/sdaa
> > > > > [root@nfs-client1 ~]# mount -t nfs -o rw,vers=4 127.0.0.1:/
> > > > > /mnt/sdaa
> > > > > [root@nfs-client1 ~]# mount | grep nfs4
> > > > > 127.0.0.1:/ on /mnt/sdaa type nfs4
> > > > > (ro,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,
> > > > > hard
> > > > > ,fat
> > > > > al_neterrors=none,proto=tcp,timeo=600,retrans=2,sec=sys,clien
> > > > > tadd
> > > > > r=12
> > > > > 7.0.0.1,local_lock=none,addr=127.0.0.1)
> > > > > 127.0.0.1:/ on /mnt/sdaa type nfs4
> > > > > (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,
> > > > > hard
> > > > > ,fat
> > > > > al_neterrors=none,proto=tcp,timeo=600,retrans=2,sec=sys,clien
> > > > > tadd
> > > > > r=12
> > > > > 7.0.0.1,local_lock=none,addr=127.0.0.1)
> > > > > 127.0.0.1:/ on /mnt/sdaa type nfs4
> > > > > (ro,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,
> > > > > hard
> > > > > ,fat
> > > > > al_neterrors=none,proto=tcp,timeo=600,retrans=2,sec=sys,clien
> > > > > tadd
> > > > > r=12
> > > > > 7.0.0.1,local_lock=none,addr=127.0.0.1)
> > > > > 127.0.0.1:/ on /mnt/sdaa type nfs4
> > > > > (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,
> > > > > hard
> > > > > ,fat
> > > > > al_neterrors=none,proto=tcp,timeo=600,retrans=2,sec=sys,clien
> > > > > tadd
> > > > > r=12
> > > > > 7.0.0.1,local_lock=none,addr=127.0.0.1)
> > > > > [root@nfs-client1 ~]# uname -a
> > > > > Linux nfs-client1 6.19.0-rc7+ #178 SMP PREEMPT_DYNAMIC Thu
> > > > > Jan 29
> > > > > 14:06:54 CST 2026 x86_64 x86_64 x86_64 GNU/Linux
> > > > > [root@nfs-client1 ~]#
> > > > > 
> > > > > [1]
> > > > > https://lore.kernel.org/all/20241114045303.1656426-1-lilingfeng3@huawei.com/
> > > > > 
> > > > > Thanks,
> > > > > Lingfeng.
> > > > What does the output of "cat /proc/fs/nfsfs/volumes" show? Does
> > > > it
> > > > show
> > > > more than 2 devices associated with that fsid?
> > > >    
> > > Here is the result of the test:
> > > 
> > > [root@nfs-client1 ~]# mount /dev/sda /mnt2
> > > [root@nfs-client1 ~]# echo "/mnt2 *(rw,no_root_squash,fsid=0)"
> > > > /etc/exports
> > > [root@nfs-client1 ~]# systemctl restart nfs-server
> > > [root@nfs-client1 ~]# mount -t nfs -o ro,vers=4 127.0.0.1:/
> > > /mnt/sdaa
> > > [root@nfs-client1 ~]# cat /proc/fs/nfsfs/volumes
> > > NV SERVER   PORT DEV          FSID FSC
> > > v4 7f000001  801 0:51         0:0                             
> > >  no
> > > [root@nfs-client1 ~]# mount -t nfs -o rw,vers=4 127.0.0.1:/
> > > /mnt/sdaa
> > > [root@nfs-client1 ~]# cat /proc/fs/nfsfs/volumes
> > > NV SERVER   PORT DEV          FSID FSC
> > > v4 7f000001  801 0:51         0:0                             
> > >  no
> > > v4 7f000001  801 0:52         0:0                             
> > >  no
> > > [root@nfs-client1 ~]# mount | grep nfs4
> > > 127.0.0.1:/ on /mnt/sdaa type nfs4
> > > (ro,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard
> > > ,fat
> > > al_neterrors=none,proto=tcp,timeo=600,retrans=2,sec=sys,clientadd
> > > r=12
> > > 7.0.0.1)
> > > 127.0.0.1:/ on /mnt/sdaa type nfs4
> > > (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard
> > > ,fat
> > > al_neterrors=none,proto=tcp,timeo=600,retrans=2,sec=sys,clientadd
> > > r=12
> > > 7.0.0.1)
> > > [root@nfs-client1 ~]# mount -t nfs -o ro,vers=4 127.0.0.1:/
> > > /mnt/sdaa
> > > [root@nfs-client1 ~]# mount -t nfs -o rw,vers=4 127.0.0.1:/
> > > /mnt/sdaa
> > > [root@nfs-client1 ~]# cat /proc/fs/nfsfs/volumes
> > > NV SERVER   PORT DEV          FSID FSC
> > > v4 7f000001  801 0:51         0:0                             
> > >  no
> > > v4 7f000001  801 0:52         0:0                             
> > >  no
> > > [root@nfs-client1 ~]# mount | grep nfs4
> > > 127.0.0.1:/ on /mnt/sdaa type nfs4
> > > (ro,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard
> > > ,fat
> > > al_neterrors=none,proto=tcp,timeo=600,retrans=2,sec=sys,clientadd
> > > r=12
> > > 7.0.0.1)
> > > 127.0.0.1:/ on /mnt/sdaa type nfs4
> > > (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard
> > > ,fat
> > > al_neterrors=none,proto=tcp,timeo=600,retrans=2,sec=sys,clientadd
> > > r=12
> > > 7.0.0.1)
> > > 127.0.0.1:/ on /mnt/sdaa type nfs4
> > > (ro,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard
> > > ,fat
> > > al_neterrors=none,proto=tcp,timeo=600,retrans=2,sec=sys,clientadd
> > > r=12
> > > 7.0.0.1)
> > > 127.0.0.1:/ on /mnt/sdaa type nfs4
> > > (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard
> > > ,fat
> > > al_neterrors=none,proto=tcp,timeo=600,retrans=2,sec=sys,clientadd
> > > r=12
> > > 7.0.0.1)
> > > [root@nfs-client1 ~]#
> > > 
> > > There are only 2 devices associated with that fsid.
> > > 
> > Then it is working as expected. It's not the kernel's job to stop
> > people from stacking one mount on top of another. If it were, then
> > the
> > right place to do that would be in the VFS and not the NFS client.
> > 
> > However the NFS client does try to ensure that mounts of the same
> > remote filesystem with the same set of mount options gets mapped to
> > the
> > same super block (and hence device). The exception is if you're
> > playing
> > with the nosharecache option; in that case you're knowingly asking
> > the
> > kernel to ignore that constraint.
> For local file systems like ext4, when I attempt to mount a file
> system
> as read-only after it has already been mounted for read and write, I
> encounter an EBUSY error (from the `get_tree` callback
> `ext4_get_tree`).
> 
> [root@nfs-client1 ~]# mount -o rw /dev/sdb /mnt3
> [root@nfs-client1 ~]# mount -o ro /dev/sdb /mnt3
> [ 2524.071442][ T1281] sdb: Can't mount, would change RO state
> mount: /mnt3: /dev/sdb already mounted on /mnt3.
> [root@nfs-client1 ~]# df -Th | grep sdb
> /dev/sdb       ext4       20G   28K   19G   1% /mnt3
> [root@nfs-client1 ~]#
> 
> Do you think NFS should have a similar restriction, allowing only one
> mount per mount point?

Why would we do that?

The above is a reflection of the fact that for ext4, the block device
can only be associated with one filesystem. After you've mounted that
block device in one place, you can't mount it read-only anywhere else.

The only way to create both a read-only and a read-write mount with
ext4 is to use a bind mount to create the read-only mount point.

NFS has no need for that restriction, so what would be the point of
duplicating it? In particular why would we want to break backward
compatibility for people who may already be relying on the current
behaviour?

-- 
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trondmy@kernel.org, trond.myklebust@hammerspace.com