Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp516301pxb; Wed, 27 Oct 2021 07:19:56 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzYz+umat5jbhDNJte3NbWT9MWkAgFF/u4sBwFc117Xz0cifLymXpMOn54Hmvma8fmVX2w0 X-Received: by 2002:a17:903:18f:b0:140:658d:851d with SMTP id z15-20020a170903018f00b00140658d851dmr13772875plg.47.1635344395979; Wed, 27 Oct 2021 07:19:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1635344395; cv=none; d=google.com; s=arc-20160816; b=yT6bvIq8jEjvDUHENGKOGOAU8jhZzHari7h+6PUAP3LR9YKYr+DaJ6EMqaZ6JuN3Gm gb75Nz1LhpuUxsYWg6f8do73p2kns7UadxDGN/uwSzvF1mFztKPDkF4G5JlCFRbFtdHF FY5m7+Va4kPieSGYOARHLCDgtwv2BpvG64GDJWulP8RTNFd+DtrB8hWmQzuQEDSm5Gln zGkWBI4jUMf4f/krU89oWrhzVXk//LdDIy4IaqJ2HBe9jZYrpT7+nLs9ihSdWn+toqiq SxJGjzR5eoGg0cdEGV8SD6urtj3cr+elx2iDhyc0UC/PwaDjEtFIeFnHJTdbjRSpg8mt b7Kw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:to:from:dkim-signature; bh=cFPBeS9arBUI/bke1rtHv1EGcG4um6xj86KYRZYByPE=; b=vLz924GVUbj5hFV7/kKpZGTXsdjGzY1zOJ773SI34hJIIgrttiLVbOr/Yr2HzLkNGC UzcT9+e7zwIRcpgO3JyaZOZFS81gQXsjd39Je5mkAT4UhsJXyyMzD+OArANcjeUJAzxX 4GgJnUo4sTRcqI2LK52JTtQn3G/BoYYnFTNl7c2OcFdxEA9WHJgyu4fiSwHfyzYwlMAS cZzJeiV5qReQesZLuSGx7Vdfs+SI6K3SsQYV5sOzIUUJyMjK53TyAKNVM+f8cglHxM1B ync899QqhpPcd0e47EOT+pep3311/lRiW9Wi6ahq6+XEMwpH4mVkPyk7QR+cwJA2PPLX 5N7g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=SBJCT0zW; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id 4si71475pgn.438.2021.10.27.07.19.24; Wed, 27 Oct 2021 07:19:55 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=SBJCT0zW; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234446AbhJ0CZw (ORCPT + 99 others); Tue, 26 Oct 2021 22:25:52 -0400 Received: from mail.kernel.org ([198.145.29.99]:55598 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233224AbhJ0CZw (ORCPT ); Tue, 26 Oct 2021 22:25:52 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 582976023F for ; Wed, 27 Oct 2021 02:23:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1635301407; bh=I57E4xwAH+YHfUM/5xdtEvjz9DkMaQIDdLO70onULnc=; h=From:To:Subject:Date:From; b=SBJCT0zWMWJMOV5JK7b9utc93GppS8xLSYOSBYIMIhXuz7FKZ3DIQjjfeeyYux3cB jTIsQN9lm/nXHnkkG95CY1ana5mAcO6pRXbaVNieUjB0HbFlzWzzYMKyFFo0lEgAHg uc0IY2lcRYQKBzKz7Q5/SruZKVq6LRojRuJpAq1GUANB+B/XWlnk4vlvMKvhzkKlSX o2qGnFyA7hfH34DeNaOm2jjJSQ3wuTvv1yI/F4fFGq3yJ2EWs/b4dbEn3SbikvaVIa h5RLMIIfZzzGXNNdiwDLhHuhpZzD4I6Z/NX/Z+87uQmVLOjfJLxDbsl9W0mZLU7NSY hvKzHmsoJLEzg== From: trondmy@kernel.org To: linux-nfs@vger.kernel.org Subject: [PATCH] NFSv4: Fix a regression in nfs_set_open_stateid_locked() Date: Tue, 26 Oct 2021 22:17:21 -0400 Message-Id: <20211027021721.58935-1-trondmy@kernel.org> X-Mailer: git-send-email 2.31.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org From: Trond Myklebust If we already hold open state on the client, yet the server gives us a completely different stateid to the one we already hold, then we currently treat it as if it were an out-of-sequence update, and wait for 5 seconds for other updates to come in. This commit fixes the behaviour so that we immediately start processing of the new stateid, and then leave it to the call to nfs4_test_and_free_stateid() to decide what to do with the old stateid. Fixes: b4868b44c562 ("NFSv4: Wait for stateid updates after CLOSE/OPEN_DOWNGRADE") Signed-off-by: Trond Myklebust --- fs/nfs/nfs4proc.c | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c index 1c485edf1d07..1c94f54cab58 100644 --- a/fs/nfs/nfs4proc.c +++ b/fs/nfs/nfs4proc.c @@ -1604,15 +1604,16 @@ static bool nfs_stateid_is_sequential(struct nfs4_state *state, { if (test_bit(NFS_OPEN_STATE, &state->flags)) { /* The common case - we're updating to a new sequence number */ - if (nfs4_stateid_match_other(stateid, &state->open_stateid) && - nfs4_stateid_is_next(&state->open_stateid, stateid)) { - return true; + if (nfs4_stateid_match_other(stateid, &state->open_stateid)) { + if (nfs4_stateid_is_next(&state->open_stateid, stateid)) + return true; + return false; } - } else { - /* This is the first OPEN in this generation */ - if (stateid->seqid == cpu_to_be32(1)) - return true; + /* The server returned a new stateid */ } + /* This is the first OPEN in this generation */ + if (stateid->seqid == cpu_to_be32(1)) + return true; return false; } -- 2.31.1