Received: by 2002:a05:6359:c8b:b0:c7:702f:21d4 with SMTP id go11csp1179766rwb; Thu, 6 Oct 2022 09:23:58 -0700 (PDT) X-Google-Smtp-Source: AMsMyM6deAgjWcvZtk3u+oUQa9vIy0yk8dha0J5ydKSv+5LPCwxfKW3ILDZAUEmKfjMN6ke/7Id6 X-Received: by 2002:a62:ee17:0:b0:55b:b0d:bc9f with SMTP id e23-20020a62ee17000000b0055b0b0dbc9fmr659304pfi.39.1665073438275; Thu, 06 Oct 2022 09:23:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1665073438; cv=none; d=google.com; s=arc-20160816; b=e9ABjv8krbPKNThvk4hJkNUbHmp1Qd/+Pz9C+noWC6Fo2QPiXI0flIZyN1QNPEA5NO rsBPae0tVSH9eXutv//J7rH7eKK669Ym8l3sU5l9addQYg6Km8SPaNSV1W2slix8uOFZ iedwzWuweirhtiXptGpz0ygXfn2uRvULteGy4fyfnGi7mggeyM4jTuDv6jHTGW4qi8CG XhJX0HS4ikJz60I2F9LY8iCJh+r62xQIl6rrtpAyPgZoO+jErB6C05G5wgrTvzEX4ySz OEyG+Nowfmqe7jAEnaBPiqb9/n8Uuy7tqY2XpOV9K5ZtxDYHK3ihRtzS/M/XztpZMxzP gESQ== 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 :user-agent:message-id:date:to:from:subject; bh=cpzy/Z+JvlmMYM3qJiXGP4Nju+aHU5jv4FR0M+KoyTQ=; b=rorZzD3QcOho8jDUmazy5VuxSf1fLorsssjxHJRt2AwVzInkG/KKTzKpCPbyB5Uc9F s9TfHk7pzHm1W+Fj5cFkcEb+7VUxp5+IUymtSeltNxr0Fdrp/CUhntDKJlC1I7wwqabm 4HOEiFfJFNQAUePSWRpXtZYw+vPi1DBKuLLknRgySNC6tAjUR5bRLgJv9F1KTGzMYHVc uDwddY7s6dLDV9cpgDEPCSJaCKE8F/qblfoJD8qECARfqO6GcRM+bolOwJrCKQwM7Ukg q7xGUhRlgA41VmraLmmRAbhhcsAr7yRGlBt47/zUn7wZZow6Oreowuvse0Ase4QJ4iCe NY9Q== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=oracle.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id w15-20020a17090a15cf00b00200919a55b1si5131742pjd.180.2022.10.06.09.23.43; Thu, 06 Oct 2022 09:23:58 -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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=oracle.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231501AbiJFQUP (ORCPT + 99 others); Thu, 6 Oct 2022 12:20:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46902 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231527AbiJFQUL (ORCPT ); Thu, 6 Oct 2022 12:20:11 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 756B332BA4 for ; Thu, 6 Oct 2022 09:20:07 -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 B1A1F60C40 for ; Thu, 6 Oct 2022 16:20:06 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1446EC433D6 for ; Thu, 6 Oct 2022 16:20:06 +0000 (UTC) Subject: [PATCH v2 0/9] A course adjustment, maybe... From: Chuck Lever To: linux-nfs@vger.kernel.org Date: Thu, 06 Oct 2022 12:20:04 -0400 Message-ID: <166507275951.1802.13184584115155050247.stgit@manet.1015granger.net> User-Agent: StGit/1.5.dev2+g9ce680a5 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.7 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_HI,SPF_HELO_NONE,SPF_PASS 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 I'm proposing this series as the first NFSD-related patchset to go into v6.2 (for-next), though I haven't opened that yet. For quite some time, we've been encouraged to disable filecache garbage collection for NFSv4 files, and I think I found a surgical way to do just that. That is presented in "NFSD: Add an NFSD_FILE_GC flag to enable nfsd_file garbage collection". Comments and opinions are welcome. Changes since RFC: - checking nfs4_files for inode aliases is now done only on hash insertion - the nfs4_file reference count is now bumped only while the RCU read lock is held - comments and function names have been revised and clarified I haven't updated the new @want_gc parameter... jury is still out. --- Chuck Lever (7): NFSD: Pass the target nfsd_file to nfsd_commit() NFSD: Revert "NFSD: NFSv4 CLOSE should release an nfsd_file immediately" NFSD: Add an NFSD_FILE_GC flag to enable nfsd_file garbage collection NFSD: Use const pointers as parameters to fh_ helpers. NFSD: Use rhashtable for managing nfs4_file objects NFSD: Clean up nfs4_preprocess_stateid_op() call sites NFSD: Trace delegation revocations Jeff Layton (2): nfsd: fix nfsd_file_unhash_and_dispose nfsd: rework hashtable handling in nfsd_do_file_acquire fs/nfsd/filecache.c | 165 +++++++++++++++--------------- fs/nfsd/filecache.h | 4 +- fs/nfsd/nfs3proc.c | 10 +- fs/nfsd/nfs4proc.c | 42 ++++---- fs/nfsd/nfs4state.c | 241 ++++++++++++++++++++++++++++++-------------- fs/nfsd/nfsfh.h | 10 +- fs/nfsd/state.h | 5 +- fs/nfsd/trace.h | 58 ++++++++++- fs/nfsd/vfs.c | 19 ++-- fs/nfsd/vfs.h | 3 +- 10 files changed, 351 insertions(+), 206 deletions(-) -- Chuck Lever