Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp2032555yba; Sun, 5 May 2019 20:53:18 -0700 (PDT) X-Google-Smtp-Source: APXvYqxHbgnNnG9yjzMrCvBwkqZKeTd1d3hYuPwwq7XC/sESU/fn9Z5USzY3TSstexzT5RQkyFxP X-Received: by 2002:a63:fa4a:: with SMTP id g10mr3138924pgk.147.1557114798319; Sun, 05 May 2019 20:53:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557114798; cv=none; d=google.com; s=arc-20160816; b=UWlwDJl5QrfSe7DMcCT8yKGnsGYfB07DH44h6JuYgbGyEqRkP5ujIea6raDyh/Kk1g 8oHUg6TNFBie4C/qRfpKjSajkw85Sehha1vSZnRRsXeMYLjQxGRZC4gQAfk3IPAWGfjC ZrCapVFFhfuARVALPUdTQ2lP4o32m2lirVJyhz8isuyfMoFJikaRSzkIaAzpKCPU2iYL sJbCZ3D8HeUTR9DRSQuTQWWMepyaS5P7k7WCqTKgMbEQ0bQu6Dzv3XGWIpTdre4fK4wI vxTIrYHfRma7HrWDe3CH+me1kcl+AbXt2n5mfTXSs2PmTQ//HDU8rwnv0ex/h3w29DLr cHJg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:subject:to :from; bh=q18WSSrJu6z+FyvDJHsvsvxCdOt9or4fudad6QX/aLQ=; b=lLA4peZY+/e4Bln63cFmiW35+wGCFFWSBLTFD4X57SEvGs+54hGp+ndZg77dAET8Tp cOv3FKsl1SbQ9jf2hAOxz3oo5eynSVhueg4zHhN1CL4jwfp0nh4h4si2kSXq4UxDyFcn q0b15NccSHkC6QS5hVL2QjnKjP9d2zkUSQZw8EUXyIr+zV4xj9sA5FxOfRT03rkhLVoX 9e0PhfTs29Frv1INLLkuyFcxbbwA63PbTpMqQsB+Kg6Rr3UzRN7q6eqnl8b2daRxOQwt f7ffl8K53Njh5Cw9RHjxHOliYADK5oVBtWJGe1gTgH6PtuTJu1T2SD1ar3Koumk68nzD IV5g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-nfs-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s4si12602758pgp.158.2019.05.05.20.52.49; Sun, 05 May 2019 20:53:18 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-nfs-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-nfs-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725827AbfEFDwr (ORCPT + 99 others); Sun, 5 May 2019 23:52:47 -0400 Received: from szxga07-in.huawei.com ([45.249.212.35]:34924 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725813AbfEFDwq (ORCPT ); Sun, 5 May 2019 23:52:46 -0400 Received: from DGGEMS409-HUB.china.huawei.com (unknown [172.30.72.60]) by Forcepoint Email with ESMTP id 7CC15A01BD6B789E204F; Mon, 6 May 2019 11:52:44 +0800 (CST) Received: from RH5885H-V3.huawei.com (10.90.53.225) by DGGEMS409-HUB.china.huawei.com (10.3.19.209) with Microsoft SMTP Server id 14.3.439.0; Mon, 6 May 2019 11:52:36 +0800 From: ZhangXiaoxu To: , , , Subject: [PATCH] NFS4: Fix v4.0 client state corruption when mount Date: Mon, 6 May 2019 11:57:03 +0800 Message-ID: <1557115023-86769-1-git-send-email-zhangxiaoxu5@huawei.com> X-Mailer: git-send-email 2.7.4 MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [10.90.53.225] X-CFilter-Loop: Reflected Sender: linux-nfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org 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 --- 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