All of lore.kernel.org
 help / color / mirror / Atom feed
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: Wed, 06 Nov 2019 11:47:02 -0500	[thread overview]
Message-ID: <21D6F3D9-C1B6-4F5C-98A0-87B067C6E198@redhat.com> (raw)
In-Reply-To: <1557115023-86769-1-git-send-email-zhangxiaoxu5@huawei.com>

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

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?

Ben

On 5 May 2019, at 23:57, ZhangXiaoxu wrote:

> stat command with soft mount never return after server is stopped.
>
> When alloc a new client, the state of the client will be set to
> NFS4CLNT_LEASE_EXPIRED.
>
> When the server is stopped, the state manager will work, and accord
> the state to recover. But the state is NFS4CLNT_LEASE_EXPIRED, it
> will drain the slot table and lead other task to wait queue, until
> the client recovered. Then the stat command is hung.
>
> When discover server trunking, the client will renew the lease,
> but check the client state, it lead the client state corruption.
>
> So, we need to call state manager to recover it when detect server
> ip trunking.
>
> Signed-off-by: ZhangXiaoxu <zhangxiaoxu5@huawei.com>
> ---
>  fs/nfs/nfs4state.c | 4 ++++
>  1 file changed, 4 insertions(+)
>
> diff --git a/fs/nfs/nfs4state.c b/fs/nfs/nfs4state.c
> index 3de3647..f502f1c 100644
> --- a/fs/nfs/nfs4state.c
> +++ b/fs/nfs/nfs4state.c
> @@ -159,6 +159,10 @@ int nfs40_discover_server_trunking(struct 
> nfs_client *clp,
>  		/* Sustain the lease, even if it's empty.  If the clientid4
>  		 * goes stale it's of no use for trunking discovery. */
>  		nfs4_schedule_state_renewal(*result);
> +
> +		/* If the client state need to recover, do it. */
> +		if (clp->cl_state)
> +			nfs4_schedule_state_manager(clp);
>  	}
>  out:
>  	return status;
> -- 
> 2.7.4


  parent reply	other threads:[~2019-11-06 16:47 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 [this message]
2019-11-07  2:34   ` zhangxiaoxu (A)
2019-11-07 13:25     ` Benjamin Coddington

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=21D6F3D9-C1B6-4F5C-98A0-87B067C6E198@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.