From patchwork Fri Mar 17 02:18:49 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Chengen Du X-Patchwork-Id: 1758043 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@legolas.ozlabs.org Authentication-Results: legolas.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=lists.ubuntu.com (client-ip=91.189.94.19; helo=huckleberry.canonical.com; envelope-from=kernel-team-bounces@lists.ubuntu.com; receiver=) Authentication-Results: legolas.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=canonical.com header.i=@canonical.com header.a=rsa-sha256 header.s=20210705 header.b=XhVWhbAs; dkim-atps=neutral Received: from huckleberry.canonical.com (huckleberry.canonical.com [91.189.94.19]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by legolas.ozlabs.org (Postfix) with ESMTPS id 4Pd79Y5d4zz247R for ; Fri, 17 Mar 2023 13:19:12 +1100 (AEDT) Received: from localhost ([127.0.0.1] helo=huckleberry.canonical.com) by huckleberry.canonical.com with esmtp (Exim 4.86_2) (envelope-from ) id 1pczgK-0004av-Ul; Fri, 17 Mar 2023 02:19:00 +0000 Received: from smtp-relay-internal-1.internal ([10.131.114.114] helo=smtp-relay-internal-1.canonical.com) by huckleberry.canonical.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1pczgG-0004aY-Kx for kernel-team@lists.ubuntu.com; Fri, 17 Mar 2023 02:18:56 +0000 Received: from mail-pj1-f72.google.com (mail-pj1-f72.google.com [209.85.216.72]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp-relay-internal-1.canonical.com (Postfix) with ESMTPS id 144CF3F1A0 for ; Fri, 17 Mar 2023 02:18:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1679019535; bh=lhTOOE/XEEtmNHRZrqKFy6yZjqz1mm6X6EZCFfJg144=; h=From:To:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version:Content-Type; b=XhVWhbAsmen8GHfbs1NLmtV4sslhbtmOvGH6tr4bLrSjHb4zV/j+qoh2TfACko3dK eGdGrm42/L1u+FGB614dzaQHa0Pt/I4jlcxvol2QRLbtfsILAT+lH1DufFqHtqCKkA VCaR4C8uXVDbGfAf0yRSXRsFDJC5gbFf1EtjV/4w7q3zckRj9g9wQcLGWhERTe7MWi 9xgWK1bwBjZnI1RBRM7vxsjkyCativRlwwceyekZEgMIHSGhFk3I48xAr03kjhmYEz Ywzet5gsrt/6OEwTKwoZwSGDf717O2EPvIkmdyTo0xN2JkGwzWY3P6uFOWBYxhuznF SunU2IoGd0SAQ== Received: by mail-pj1-f72.google.com with SMTP id oa14-20020a17090b1bce00b0023d1b58d3baso1673716pjb.4 for ; Thu, 16 Mar 2023 19:18:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679019533; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=lhTOOE/XEEtmNHRZrqKFy6yZjqz1mm6X6EZCFfJg144=; b=g8aFJva25LIVqGVgfeMrQLrj7HXSfvB4/LFqi68tdX2hl/V5Q5Ng5aqJOmWK/3KXr1 OtEHeZJbQAuB6VAGH2++fUTTyMbE7MMs2/4r6eGb6iwJtcv4Zmm5rbZBPNnD0QgLsUep dFLUsp3lL/of6XL+tsq3rEJLNDgaGvqodAAdZoCmazmK/+/wb26/vo4S32Z2HitgY4mW V4tfsvucCc37F7pRUusjRlTi9ehlpNOxjnNlBTPicX3KnftS+KcmsexntztjHdsnMkdX fw+POkQrDkw2m/kqv/ENxCj8+wPhxURRQWq2FkHzjz6Rsl0XWUeX5Gy80jp1eHZVXrZr KnmQ== X-Gm-Message-State: AO0yUKXORUwfH9YKwh9CIRDCDfis2bakP9f65k7aLxk21IbTN7W7ZZgc 0HfYgGEVnCtMkZC5BbF1HyOp8yMwSmqnhl0b4AUrIuhw0kxyHf0DTzJwGEdabpldYN4sDuNYejM AoXvGViM/dC9A+mE4fWj6SMlZsK/DpNgrvP7YTLCaSg0QlkbCNw== X-Received: by 2002:a17:90b:1c8e:b0:234:b4a7:2abd with SMTP id oo14-20020a17090b1c8e00b00234b4a72abdmr6578398pjb.12.1679019533550; Thu, 16 Mar 2023 19:18:53 -0700 (PDT) X-Google-Smtp-Source: AK7set8LMJpu2FjTqOGLQQu4Sv4Ez4L3Bvw2QZzZJG41Av4Im3Ib93J49NXdw5S2CklkNy0cbg2srw== X-Received: by 2002:a17:90b:1c8e:b0:234:b4a7:2abd with SMTP id oo14-20020a17090b1c8e00b00234b4a72abdmr6578382pjb.12.1679019533161; Thu, 16 Mar 2023 19:18:53 -0700 (PDT) Received: from chengendu.. (111-248-125-11.dynamic-ip.hinet.net. [111.248.125.11]) by smtp.gmail.com with ESMTPSA id g9-20020a170902934900b0019f1205bdcbsm351338plp.147.2023.03.16.19.18.52 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 16 Mar 2023 19:18:52 -0700 (PDT) From: Chengen Du To: kernel-team@lists.ubuntu.com Subject: [SRU][Bionic][PATCH 1/1] NFS: Correct timing for assigning access cache timestamp Date: Fri, 17 Mar 2023 10:18:49 +0800 Message-Id: <20230317021849.22643-2-chengen.du@canonical.com> X-Mailer: git-send-email 2.37.2 In-Reply-To: <20230317021849.22643-1-chengen.du@canonical.com> References: <20230317021849.22643-1-chengen.du@canonical.com> MIME-Version: 1.0 X-BeenThere: kernel-team@lists.ubuntu.com X-Mailman-Version: 2.1.20 Precedence: list List-Id: Kernel team discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kernel-team-bounces@lists.ubuntu.com Sender: "kernel-team" From: Chengen Du BugLink: https://bugs.launchpad.net/bugs/2009325 When the user's login time is newer than the cache's timestamp, the original entry in the RB-tree will be replaced by a new entry. Currently, the timestamp is only set if the entry is not found in the RB-tree, which can cause the timestamp to be undefined when the entry exists. This may result in a significant increase in ACCESS operations if the timestamp is set to zero. Signed-off-by: Chengen Du Fixes: 0eb43812c027 ("NFS: Clear the file access cache upon login”) Reviewed-by: Benjamin Coddington Signed-off-by: Anna Schumaker (cherry picked from commit 21fd9e8700de86d1169f6336e97d7a74916ed04a) Signed-off-by: Chengen Du --- fs/nfs/dir.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/nfs/dir.c b/fs/nfs/dir.c index b98b19ca367c..5c05140d5d2e 100644 --- a/fs/nfs/dir.c +++ b/fs/nfs/dir.c @@ -2416,7 +2416,6 @@ static void nfs_access_add_rbtree(struct inode *inode, struct nfs_access_entry * else goto found; } - set->timestamp = ktime_get_ns(); rb_link_node(&set->rb_node, parent, p); rb_insert_color(&set->rb_node, root_node); list_add_tail(&set->lru, &nfsi->access_cache_entry_lru); @@ -2438,6 +2437,7 @@ void nfs_access_add_cache(struct inode *inode, struct nfs_access_entry *set) RB_CLEAR_NODE(&cache->rb_node); cache->cred = get_rpccred(set->cred); cache->mask = set->mask; + cache->timestamp = ktime_get_ns(); /* The above field assignments must be visible * before this item appears on the lru. We cannot easily