Re: [PATCH] nfs: pass flags to second superblock

[Li Lingfeng <lilingfeng3@huawei.com>]

Hi Anna,

We found that this modification clears the flags (SB_BORN/SB_ACTIVE/
SB_POSIXACL) already set in the superblock, which would cause problems.
We will redesign a solution to address the original issue.
Sorry for the noise.

Thanks,
Li

在 2024/11/26 6:34, Anna Schumaker 写道:
> Hi Li,
>
> On Wed, Nov 13, 2024 at 11:33 PM Li Lingfeng <lilingfeng3@huawei.com> wrote:
>> 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).
>>
>> Since the superblock of NFS does not carry the ro tag, the file system
>> status displayed by /proc/self/mountstats shows that NFS is always in the
>> rw state, which may mislead users.
>>
>> Pass sb_flags of the fc which carry flags passed by user to second
>> superblock to fix it.
>>
>> Fixes: 281cad46b34d ("NFS: Create a submount rpc_op")
>> Signed-off-by: Li Lingfeng <lilingfeng3@huawei.com>
>> ---
>>   fs/nfs/nfs4super.c | 1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git a/fs/nfs/nfs4super.c b/fs/nfs/nfs4super.c
>> index b29a26923ce0..9a3b73a33fbf 100644
>> --- a/fs/nfs/nfs4super.c
>> +++ b/fs/nfs/nfs4super.c
>> @@ -233,6 +233,7 @@ static int do_nfs4_mount(struct nfs_server *server,
>>          if (IS_ERR(dentry))
>>                  return PTR_ERR(dentry);
>>
>> +       dentry->d_sb->s_flags = fc->sb_flags;
> I'm seeing a handful of new xfstests failures that I bisected to this
> patch: generic/157, generic/184, generic/306, generic/564, and
> generic/598.
>
> I'm seeing this on NFS v4.1 and v4.2, and it looks like each one of
> these failures is due to a new -EIO error being generated. Any
> thoughts about what could be causing this?
>
> Thanks,
> Anna
>
>
>>          fc->root = dentry;
>>          return 0;
>>   }
>> --
>> 2.31.1
>>
>