From patchwork Sun Sep 20 15:04:22 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kinglong Mee X-Patchwork-Id: 7226091 Return-Path: X-Original-To: patchwork-linux-nfs@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id BD4FF9F372 for ; Sun, 20 Sep 2015 15:04:37 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id DCA93208ED for ; Sun, 20 Sep 2015 15:04:36 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id DFF462074A for ; Sun, 20 Sep 2015 15:04:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752651AbbITPEf (ORCPT ); Sun, 20 Sep 2015 11:04:35 -0400 Received: from mail-pa0-f54.google.com ([209.85.220.54]:35392 "EHLO mail-pa0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752583AbbITPEe (ORCPT ); Sun, 20 Sep 2015 11:04:34 -0400 Received: by pacfv12 with SMTP id fv12so95014586pac.2 for ; Sun, 20 Sep 2015 08:04:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:cc:from:subject:message-id:date:user-agent:mime-version :content-type:content-transfer-encoding; bh=Iaymd7SiLxuLLKs24k/96nXx+QjWukNv2Y7QiIwKyvc=; b=Ec6ka9GVSW9YboJRYXpNeiiiR45QXyS0HYe8EAFG1US0apt1bErsPq+4di/o9ZrJqQ 35n41f33ZGiSpfiStFszASeXcdb9vhXJLWJbKEruJU7b6D3AAF0deMhJECEnt8OiGa1w CQ3cqRxMOa5WbiEN0IQ4q5VHOU4ELdoKdOoH+OaX1eu6Vs+rBaDjTlRFVAG/cE26K1OD OL7qQ0o3b97mX0u0MfVA2slNxKjEEz3nBeKSv5uLg8Xp76S9344h8yBMylGApSvELmrf RH8+oqGZhAMwidvqb7/QsUbP0isujIUqBrXXzA7RDk6loe3IgWIITuFCM9QXTA3HNFhe J/7g== X-Received: by 10.68.135.69 with SMTP id pq5mr19122874pbb.162.1442761474182; Sun, 20 Sep 2015 08:04:34 -0700 (PDT) Received: from [192.168.99.2] ([104.143.41.79]) by smtp.googlemail.com with ESMTPSA id yi8sm19496295pab.22.2015.09.20.08.04.28 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 20 Sep 2015 08:04:33 -0700 (PDT) To: Trond Myklebust Cc: "linux-nfs@vger.kernel.org" , Christoph Hellwig From: Kinglong Mee Subject: [PATCH 2/2] NFS: Fix an infinite loop when layoutget fail with BAD_STATEID Message-ID: <55FECAF6.7070406@gmail.com> Date: Sun, 20 Sep 2015 23:04:22 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Sender: linux-nfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, RCVD_IN_DNSWL_HI, T_DKIM_INVALID, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP If layouget fail with BAD_STATEID, restart should not using the old stateid. But, nfs client choose the layout stateid at first, and then the open stateid. To avoid the infinite loop of using bad stateid for layoutget, this patch sets the layout flag'ss NFS_LAYOUT_INVALID_STID bit to skip choosing the bad layout stateid. Signed-off-by: Kinglong Mee --- fs/nfs/nfs4proc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c index 693b903..10ba6c1 100644 --- a/fs/nfs/nfs4proc.c +++ b/fs/nfs/nfs4proc.c @@ -7820,6 +7820,7 @@ static void nfs4_layoutget_done(struct rpc_task *task, void *calldata) * Mark the bad layout state as invalid, then retry * with the current stateid. */ + set_bit(NFS_LAYOUT_INVALID_STID, &lo->plh_flags); pnfs_mark_matching_lsegs_invalid(lo, &head, NULL); spin_unlock(&inode->i_lock); pnfs_free_lseg_list(&head);