From: "Benjamin Coddington" <bcodding@redhat.com>
To: zhangxiaoxu <zhangxiaoxu5@huawei.com>
Cc: trond.myklebust@hammerspace.com, anna.schumaker@netapp.com,
linux-nfs@vger.kernel.org
Subject: Re: [PATCH] NFS4: Fix v4.0 client state corruption when mount
Date: Thu, 07 Nov 2019 08:25:53 -0500 [thread overview]
Message-ID: <5CD73EBD-7D20-4DC3-A496-B870BB95638B@redhat.com> (raw)
In-Reply-To: <6348ccfd-4a61-5e82-fd2a-03b2c18fe220@huawei.com>
On 6 Nov 2019, at 21:34, zhangxiaoxu (A) wrote:
> 在 2019/11/7 0:47, Benjamin Coddington 写道:
>> Hi ZhangXiaoxu,
>>
>> I'm having a bit of trouble with this fix (which went upstream in
>> f02f3755dbd14fb935d24b14650fff9ba92243b8).
>>
>> Since this change, my client calls SETCLIENTID/SETCLIENTID_CONFIRM
>> twice in
>> quick succession on mount, and the second SETCLIENTID_CONFIRM sent by
>> the state
>> manager can sometimes have the same verifier sent back by the first
>> SETCLIENTID's response. I think we're missing a memory barrier
>> somewhere..
>
> nfs40_discover_server_trunking
> nfs4_proc_setclientid # the first time
>
> after nfs4_schedule_state_manager, the state manager:
> nfs4_run_state_manager
> nfs4_state_manager
> # 'nfs4_alloc_client' init state to NFS4CLNT_LEASE_EXPIRED
> nfs4_reclaim_lease
> nfs4_establish_lease
> nfs4_init_clientid
> nfs4_proc_setclientid # the second time.
>
>>
>> But, I do not understand how the client was able to corrupt the state
>> before
>> this patch, and I don't understand how the patch fixes state
>> corruption.
>>
>> Can anyone enlighten me as to how we were corrupting state here?
> when 'nfs4_alloc_client', the client state initialized with
> 'NFS4CLNT_LEASE_EXPIRED',
> So, we should recover it when the client init.
Why? The commit message asserts that if we don't, there will be
corruption
of the client's state. How can the client's state be corrupted?
> After the first setclientid, maybe we should clear the
> 'NFS4CLNT_LEASE_EXPIRED', then
> the state manager won't be called it again.
What about just never setting it in nfs4_alloc_client? It has been set
there
since 286d7d6a0cb, and that commit needed it because it changed the
paths so
that the only way to ever send a SETCLIENTID was through state recovery.
Today, we have two paths - the trunking discovery for new clients as
well as
state recovery, and all new clients will go through trunking discovery.
Removing the call to kick the state manager thread will fix the problem
that the update to cl_confirm happens after the state manager has
already
started doing its own SETCLIENTID dance.
Ben
prev parent reply other threads:[~2019-11-07 13:26 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-06 3:57 [PATCH] NFS4: Fix v4.0 client state corruption when mount ZhangXiaoxu
2019-05-13 1:48 ` zhangxiaoxu (A)
2019-11-06 16:47 ` Benjamin Coddington
2019-11-07 2:34 ` zhangxiaoxu (A)
2019-11-07 13:25 ` Benjamin Coddington [this message]
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=5CD73EBD-7D20-4DC3-A496-B870BB95638B@redhat.com \
--to=bcodding@redhat.com \
--cc=anna.schumaker@netapp.com \
--cc=linux-nfs@vger.kernel.org \
--cc=trond.myklebust@hammerspace.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).