Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp2742346pxv; Sat, 3 Jul 2021 19:41:33 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwK8xqwKP8LOnKGzNDpy59qr2siZR0vxlhawaJr5wV2BM1KtT532xQw7Hs+qI+C4chVLRZa X-Received: by 2002:a17:906:9c84:: with SMTP id fj4mr4590606ejc.264.1625366493187; Sat, 03 Jul 2021 19:41:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1625366493; cv=none; d=google.com; s=arc-20160816; b=Ez8vKUT8m0IH0eKnZ+DZ7HRicPCacqSOHyPuMwOTfdzdrMifLnPDEvEKZrNrCNglIs qbNP18lNu6ketIGEy47McYfZE74S4iVy1nYMaH8wBKtHSuEAr558ILKifA4s3MFjm9bc acMd3eLs8wVr1INOWdnfbiCCAnjBYuvTMF6gvoWN3sgVrBE/bpexJEn6cufun4em/LmM 0Z/knaYxvGoH7LTnisjRlAnXqi03lZinua/GZboFab1V4uKRGWYKhX9bBwi3mewTfdxO VyKKUfewdjqzstjcC7BFMUkid22BnP9vzxkW1oS2CqgEE0bRPwudR4cY3o4sSp3e3JG/ QofQ== 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=iUlZscCDq9pyESgPZSzUFjHhGPDjLxL4ueSQqLExhp8=; b=vt27XnYMdgJhaMKaXDhYhhlQPh0Ff5Op3g5JkkendeYrItq1UFA2lmdj0zxq+q93zK nr7Q3SJPWNLnnj1ElVjNKgaHrwMztElQu3aHcU/sYrNJBBm+pXxvl8JYPYCxpOKlHN/Z 40Fkcl3paSChhBZQUwKDSUugfS5RvgyPAmzxs0o6xcVSRr4ZyKvDuEjgRA7RK9cZMwiD HBwDGRXwcO0/bRPnbeOVv2hilCIDxWbAmiLKfk9ZNd4P1zi1116azLPs7vWozIfAJ+Nv 1bd1gbCor9KS/a7KNeoIkURV1iscioui60LpuwAAebagvVnVpHjoPK0rWWfdhIl0kCRz jnrA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=B28UK+pB; 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 f8si7345324ejl.652.2021.07.03.19.40.51; Sat, 03 Jul 2021 19:41:33 -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=B28UK+pB; 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 S229613AbhGDCHr (ORCPT + 99 others); Sat, 3 Jul 2021 22:07:47 -0400 Received: from mail.kernel.org ([198.145.29.99]:36580 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229529AbhGDCHq (ORCPT ); Sat, 3 Jul 2021 22:07:46 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id EDF27615A0 for ; Sun, 4 Jul 2021 02:05:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1625364312; bh=sI8IU2PYDhcRh+Oz/8+AP47sYfBngTBxJDelVCfFaks=; h=From:To:Subject:Date:From; b=B28UK+pBj9memlZXu/fSKAHcZtW80mGe2aPTTGtf3NWCvRyt5XYDJz0FLDjAD83n1 0HKi4s2LuvrqPJ8AO8IArzOnwZZ70tJpI0pT5mvSvlfL+QMeNDw/egp69O8l4HEOBe eDawD2Tym6jxLixYsebuHCl7KzlJX5jIxTyNifGSyjPIU48VuHjbqfqZ9ueVdjqSe3 c33pQxJURnYrQQ87czBRIvTg+5XMVkSwnugqMwKeNKLZz+UCSK5prP2q3/5cIeygxx CQZRls+wajHPxYry5bvgM2ETc3lRdIS2b3nISoBdH14FL01sarbfD9IGj+Nlqzzkxg tElaFCsvb/+8g== From: trondmy@kernel.org To: linux-nfs@vger.kernel.org Subject: [PATCH 1/5] NFSv4/pnfs: Fix the layout barrier update Date: Sat, 3 Jul 2021 22:05:06 -0400 Message-Id: <20210704020510.4898-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 have multiple outstanding layoutget requests, the current code to update the layout barrier assumes that the outstanding layout stateids are updated in order. That's not necessarily the case. Instead of using the value of lo->plh_outstanding as a guesstimate for the window of values we need to accept, just wait to update the window until we're processing the last one. The intention here is just to ensure that we don't process 2^31 seqid updates without also updating the barrier. Fixes: 1bcf34fdac5f ("pNFS/NFSv4: Update the layout barrier when we schedule a layoutreturn") Signed-off-by: Trond Myklebust --- fs/nfs/pnfs.c | 30 +++++++++++++++--------------- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/fs/nfs/pnfs.c b/fs/nfs/pnfs.c index 2c01ee805306..ffe02e43f8c0 100644 --- a/fs/nfs/pnfs.c +++ b/fs/nfs/pnfs.c @@ -966,10 +966,8 @@ void pnfs_set_layout_stateid(struct pnfs_layout_hdr *lo, const nfs4_stateid *new, const struct cred *cred, bool update_barrier) { - u32 oldseq, newseq, new_barrier = 0; - - oldseq = be32_to_cpu(lo->plh_stateid.seqid); - newseq = be32_to_cpu(new->seqid); + u32 oldseq = be32_to_cpu(lo->plh_stateid.seqid); + u32 newseq = be32_to_cpu(new->seqid); if (!pnfs_layout_is_valid(lo)) { pnfs_set_layout_cred(lo, cred); @@ -979,19 +977,21 @@ pnfs_set_layout_stateid(struct pnfs_layout_hdr *lo, const nfs4_stateid *new, clear_bit(NFS_LAYOUT_INVALID_STID, &lo->plh_flags); return; } - if (pnfs_seqid_is_newer(newseq, oldseq)) { + + if (pnfs_seqid_is_newer(newseq, oldseq)) nfs4_stateid_copy(&lo->plh_stateid, new); - /* - * Because of wraparound, we want to keep the barrier - * "close" to the current seqids. - */ - new_barrier = newseq - atomic_read(&lo->plh_outstanding); - } - if (update_barrier) - new_barrier = be32_to_cpu(new->seqid); - else if (new_barrier == 0) + + if (update_barrier) { + pnfs_barrier_update(lo, newseq); return; - pnfs_barrier_update(lo, new_barrier); + } + /* + * Because of wraparound, we want to keep the barrier + * "close" to the current seqids. We really only want to + * get here from a layoutget call. + */ + if (atomic_read(&lo->plh_outstanding) == 1) + pnfs_barrier_update(lo, be32_to_cpu(lo->plh_stateid.seqid)); } static bool -- 2.31.1