From patchwork Wed Jun 27 18:18:25 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Trond Myklebust X-Patchwork-Id: 10492363 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id A3EE260230 for ; Wed, 27 Jun 2018 18:18:55 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id A644D2991F for ; Wed, 27 Jun 2018 18:18:55 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 9AA04299AB; Wed, 27 Jun 2018 18:18:55 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.8 required=2.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI, T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 46A6B2991F for ; Wed, 27 Jun 2018 18:18:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965749AbeF0SSy (ORCPT ); Wed, 27 Jun 2018 14:18:54 -0400 Received: from mail-io0-f193.google.com ([209.85.223.193]:34475 "EHLO mail-io0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965736AbeF0SSw (ORCPT ); Wed, 27 Jun 2018 14:18:52 -0400 Received: by mail-io0-f193.google.com with SMTP id e15-v6so2778231iog.1 for ; Wed, 27 Jun 2018 11:18:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:in-reply-to:references:mime-version :content-transfer-encoding; bh=w1Sp0cUM34sQ89dlHvUEdum0krnBxeoX3v1KitQtJho=; b=bv2LWDztIHfafq9feRHZ0KSBtftt2JM0yYUmklEo+35WtnXJ/r0OxBDKzyGuQfijCY UdmdTZak3ArgH1DGK1cd494uUr4uehb2lFXKlzZMSDg/c0ePVOIErFDoCYz35kbk5Fy7 WOnt0CZHjl+vS6GoDhAMb8tD083TvBZymqq0ThIxykA5jQmEcEzg91DMcxgVLOocZYwS 3rznSYwxHxh3BC6D4j3p/BtlVssNwIGDJn2h4vGhOMEjX2cuZYthVmd3fkUyfhyY7G9z 2gYwRjOXViKTRCXtELGONW0XLJya0wxDzTzfLk03NG6NMbCTD/r22WF6dDW9uUSfQ38i N+0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=w1Sp0cUM34sQ89dlHvUEdum0krnBxeoX3v1KitQtJho=; b=aDse0jx50Q4YVodjSTUWFBp0o5WUWAt9eXexChDFCqRiiw/lUWDIg5CT9NcqknSNT0 JvItSNy0hdSywhq+7d3kf1M7d1LW2vF5aQRUJX/idtt9x6S9ZZbKjAa1J87GHHLY1hlM NOSL9VbPJIkqUQXZf+BhdqN+PPP4zxQpCRF+Rmrzu0Ibs0E5SjatAQGIFbvpzjC3H2pd XExbQ29A16+XAZs5iBZWnou55Og7lxUeOsYP5OHyUsgUHBEoGmqslhDpXu/N3afTna0e dNhaRZJ044nvP5cijkL5VQx3JwVIxviOtQiTFuJ9wXslvWPxNK6DA+PDRb6XXij/rePQ CWtA== X-Gm-Message-State: APt69E1YpRP5SaWC0Pfdg+Z7lyIyLzauhAGrTeZQteInvHEHH6LqBCjr vBJL+bNyEgG5UzVKKU4s7NkRy1o= X-Google-Smtp-Source: AAOMgpeyPXZvwU6Y/PGwgxxOvLXkl5i3bpLtMHeaQxhd4O//PCMJCHgEqd5KtpIfFIkhny3aeDkhqA== X-Received: by 2002:a5e:8515:: with SMTP id i21-v6mr5711148ioj.301.1530123531942; Wed, 27 Jun 2018 11:18:51 -0700 (PDT) Received: from leira.trondhjem.org.localdomain ([50.105.87.45]) by smtp.gmail.com with ESMTPSA id x5-v6sm2105233ioa.65.2018.06.27.11.18.51 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 27 Jun 2018 11:18:51 -0700 (PDT) From: Trond Myklebust X-Google-Original-From: Trond Myklebust To: linux-nfs@vger.kernel.org Subject: [PATCH 2/5] pNFS: Don't update the stateid when replying NFS4ERR_DELAY to a layout recall Date: Wed, 27 Jun 2018 14:18:25 -0400 Message-Id: <20180627181828.27680-2-trond.myklebust@hammerspace.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20180627181828.27680-1-trond.myklebust@hammerspace.com> References: <20180627181828.27680-1-trond.myklebust@hammerspace.com> MIME-Version: 1.0 Sender: linux-nfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP RFC5661 doesn't state directly that the client should update the layout stateid if it returns NFS4ERR_NOMATCHING_LAYOUT in response to a recall, however it does state that this error will "cleanly indicate completion" on par with returning the layout. For this reason, we assume that the client should update the layout stateid. The Linux pNFS server definitely does expect this behaviour. However, if the client replies NFS4ERR_DELAY, then it is stating that the recall was not processed, so it would be very wrong to update the layout stateid. Signed-off-by: Trond Myklebust --- fs/nfs/callback_proc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/nfs/callback_proc.c b/fs/nfs/callback_proc.c index af2322256aa4..efca3d6c89f2 100644 --- a/fs/nfs/callback_proc.c +++ b/fs/nfs/callback_proc.c @@ -273,7 +273,6 @@ static u32 initiate_file_draining(struct nfs_client *clp, rv = pnfs_check_callback_stateid(lo, &args->cbl_stateid); if (rv != NFS_OK) goto unlock; - pnfs_set_layout_stateid(lo, &args->cbl_stateid, true); /* * Enforce RFC5661 Section 12.5.5.2.1.5 (Bulk Recall and Return) @@ -283,6 +282,7 @@ static u32 initiate_file_draining(struct nfs_client *clp, goto unlock; } + pnfs_set_layout_stateid(lo, &args->cbl_stateid, true); switch (pnfs_mark_matching_lsegs_return(lo, &free_me_list, &args->cbl_range, be32_to_cpu(args->cbl_stateid.seqid))) {