Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp845023rwd; Wed, 7 Jun 2023 07:38:09 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ6tzbesy/Pd9GpnaTb03U/cGp0nEAzlSgXV00BEaACb+fIxcKL6g8KNI7NQ73R1McQS2e/g X-Received: by 2002:a17:902:ea0d:b0:1b0:3a74:7fc4 with SMTP id s13-20020a170902ea0d00b001b03a747fc4mr4276501plg.24.1686148688762; Wed, 07 Jun 2023 07:38:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1686148688; cv=none; d=google.com; s=arc-20160816; b=JvvpNU3zWwLbN/Vxkq6xUqAsdn2S5ID2KzekkazNJ6b4K2BPfiOoEo1JveHVL3XTr0 wJEdQfjuqq4aL8u+gUD2TsO7NKE7yzyk8KowVi1IadC6nlHlzwj7DKJMnkIVjL9LgiC5 kX9VOBU2B2d+UJolqgKGLqAuRUSriGH9t4r9mxn/U11Fd4Egc0xEyODh+THOwo9+DyLg koT4tflwUsoLLnBZ4W2/VHsnRDTuBnxMyLYawbLkhURbkrwYJKQE+z/12sDR/NyPtqEh kPLHPKeXFpZwmfPlc0+pQ7VP55CN12x/V5nmK7udGZc9w2AgZ0cBrdwb4424pzVpxgNa 9Oaw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=w1HTBnvKOIlrVOFWc9M4UVQV0XOunJUdMSzq3YwzCPo=; b=GU3mz6p7jARWs8eXrkWFI9An9eT0lp7bi1tFWuhngX5yRxd+351e3klM7kax5QlUnU 172qY7B57fPRlRQ40efvp9LFzsPcWjYJ+HpRAdjxhPnaDE06WnngEjzRb4yGueRFNI4D /vsVQZMiPCEyxrrMlpFJURBQoYZscV1wW/Pzf8nw/9P3oyoOZol6doIztewGuCVaY439 YbmoEZXdzHuG15X8MMg1NEwKXCYiCcWAaHUP5RkPAAKDK3zd2FptE+0UpEaF4sU5xOhd qjwK2ZcUKws4z8C964p0j8mRCRJAasQvTDfHk4tYacbD8fTJl4mzWF6052QFQIoPoB4G iSFA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=W5enn6d2; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 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 out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id lg13-20020a170902fb8d00b001a4fc13dfa5si8655906plb.276.2023.06.07.07.37.50; Wed, 07 Jun 2023 07:38:08 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=W5enn6d2; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 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 S234954AbjFGOZz (ORCPT + 99 others); Wed, 7 Jun 2023 10:25:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54620 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234655AbjFGOZz (ORCPT ); Wed, 7 Jun 2023 10:25:55 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 627951AE for ; Wed, 7 Jun 2023 07:25:54 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id F2D4B63FCB for ; Wed, 7 Jun 2023 14:25:53 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id F396CC433EF; Wed, 7 Jun 2023 14:25:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1686147953; bh=41OI6P/XHQ1yHNJnYWeXhhwFG2qd4WwF82QPvok0Ve4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=W5enn6d2zWgzBguwjY79/bohj8wicksL0kZlmnX14hS7DlR4LdsmIYkXKbb7Rdnl4 pO+1zKkbcYMddU1z9PT2QAAr4J2jYRq8uWIISiEbYkJt17CTjKcMJe1rDfuQ31b6A7 XchGXJCGVOAGE1rYd7reIIBGBYJy4xCAFwYLcRRBuyWSRD9genupolA1eOfPXQAw1+ sCG/3vfpZyPI7/Lt1SRGwo3Ehhh9O0SPn2hXawmX5j6UMI/1Jn+DJK0zO176OYU2DQ t1asAi4SJXmpwY/K0vmFqqhDh6jAlT9Gr0Thzcc72qsRfZQ2DnFsWJnzk7v2g22xQ6 FGTWYP1ej/BRQ== Date: Wed, 7 Jun 2023 10:25:50 -0400 From: Chuck Lever To: Dai Ngo Cc: chuck.lever@oracle.com, jlayton@kernel.org, linux-nfs@vger.kernel.org Subject: Re: [PATCH 1/1] NFSD: remove dead code in nfs4_open_delegation Message-ID: References: <1686094819-13044-1-git-send-email-dai.ngo@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1686094819-13044-1-git-send-email-dai.ngo@oracle.com> X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org On Tue, Jun 06, 2023 at 04:40:19PM -0700, Dai Ngo wrote: > The intention of this code is to tell the client to return the granted > delegation immediately for whatever reason in the case of OPEN with > NFS4_OPEN_CLAIM_PREVIOUS. However this was already handled above in the > cases of switch(open->op_claim_type). > > Signed-off-by: Dai Ngo > --- > fs/nfsd/nfs4state.c | 5 ----- > 1 file changed, 5 deletions(-) > > diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c > index 6b75656d3e8f..58c78a23f90b 100644 > --- a/fs/nfsd/nfs4state.c > +++ b/fs/nfsd/nfs4state.c > @@ -5632,11 +5632,6 @@ nfs4_open_delegation(struct nfsd4_open *open, struct nfs4_ol_stateid *stp, > return; > out_no_deleg: > open->op_delegate_type = NFS4_OPEN_DELEGATE_NONE; > - if (open->op_claim_type == NFS4_OPEN_CLAIM_PREVIOUS && > - open->op_delegate_type != NFS4_OPEN_DELEGATE_NONE) { > - dprintk("NFSD: WARNING: refusing delegation reclaim\n"); > - open->op_recall = 1; > - } This is dead code because it's broken. Look carefully at it: it sets open->op_delegate_type to NONE, then prints a warning if it isn't NONE. The warning will never occur, and neither will the recall. This code came from 99c415156c49 ("nfsd4: clean up nfs4_open_delegation"). Can you have a look at that old commit and make sure nfs4_open_delegation is working as it was originally intended before it was cleaned up by that commit? Even if you decide not to change the diff, the patch description is confusing. out_no_deleg: can be invoked /after/ the switch statement, so I'm not seeing how the OPEN/CLAIM_PREVIOUS case is handled in that instance. The description also needs to at least mention that the removed code never worked properly. > /* 4.1 client asking for a delegation? */ > if (open->op_deleg_want) > -- > 2.9.5 >