linux-kernel - Re: [PATCH] nfs: pass flags to second superblock

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <728568ef-4563-4860-9490-e53aa4f6dd76@huawei.com>
Date: Thu, 28 Nov 2024 22:17:01 +0800
From: Li Lingfeng <lilingfeng3@...wei.com>
To: Anna Schumaker <anna@...nel.org>
CC: <trondmy@...nel.org>, <trond.myklebust@...merspace.com>,
	<jlayton@...nel.org>, <linux-nfs@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, <yukuai1@...weicloud.com>,
	<houtao1@...wei.com>, <yi.zhang@...wei.com>, <yangerkun@...wei.com>,
	<lilingfeng@...weicloud.com>
Subject: Re: [PATCH] nfs: pass flags to second superblock

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@...wei.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@...wei.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
>>
>