From patchwork Fri Mar 17 02:23:26 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Chengen Du X-Patchwork-Id: 1758051 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=LrKKAM7c; 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 4Pd7Gh6wpvz1yWp for ; Fri, 17 Mar 2023 13:23:40 +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 1pczkj-00069I-DO; Fri, 17 Mar 2023 02:23:33 +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 1pczki-000692-Nj for kernel-team@lists.ubuntu.com; Fri, 17 Mar 2023 02:23:32 +0000 Received: from mail-pj1-f71.google.com (mail-pj1-f71.google.com [209.85.216.71]) (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 78FE73F1F2 for ; Fri, 17 Mar 2023 02:23:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1679019812; bh=zWF8S9ZsizRmSpoW40gcxN8YcPyF4W1CctAeExsuiLk=; h=From:To:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version:Content-Type; b=LrKKAM7cY5Pu0NKzI9AyTvrtRiyWHHqbEPUKlDEhi0RLa3rUApdt1H/0GzCvIeAjV CTdY/1oBmrgiMfM6wJ+Y9RxxZjhRvuvg8/VpOJ5C92pD2g56NQnMpboEMEOllQPes9 lTpmH05mJC1vvlTtkMO67KUdcmm0120tYi+FgWJM/9k9Oa0yGXT8W0gQHonQ7wiiyn 7/4YlXzFCtnqcREIqva41sP82KOGEEpPztZyW+3RIyVDJFZgI0/4gibA3PoAh83xeW NmzcOJYB45TQCSyeOAfYZX1W1kbdhvOGkWK7QKgFzrk85zP1RGJWAmg+RnjykPVzLH 1gF3QI9vxJ9YQ== Received: by mail-pj1-f71.google.com with SMTP id o89-20020a17090a0a6200b0023b3d3acdd6so3378714pjo.3 for ; Thu, 16 Mar 2023 19:23:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679019810; 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=zWF8S9ZsizRmSpoW40gcxN8YcPyF4W1CctAeExsuiLk=; b=rfcAlVEH+YiiKpXagDvX5dbKg2HblNkatq8nlL2UMcyYRUFc7dCemTAdjEmphiy3vT l7W/mOq1AiHIh1+H3T31LIN1F6a5yId5l3o5wxE+1Pm72S45X+8DPiKgOkmwn8O3UVWs hzkplUa6MsDABdVFj1eeQqpfYB/ANIm6UlJRjsJsicWvG0sI/d1I+WU3hDpv/p9JaYYq V4pFlRBj1kLgcZLmTt2RdmINCvVposYbuSVuZM0KRR73Jt/d2tdUeXFVTUquG6NBmnEQ 3dJRRPv6xuQZlj4HARdVYorH47vJ2pYEsDAwy15g2ysp7S0ZjdsSQRaSt/CWP6NoPHFY 1q5g== X-Gm-Message-State: AO0yUKXfa828qLowzROtVCtKdz/cZvveg7jiPJToTDwmytN8/Zcp3ew6 HnWTjDYxWfXTJorLVMVsZFid1SrrfEmUn73H+uZOv6S+NUWwO62bx94gDX1MKMYV5858YTuDV4G 125SFuvy2UQXXWboGtL+1Dw1jJoJ6zvIQoyb8poAeibZGV2iKkQ== X-Received: by 2002:a17:902:db08:b0:1a0:6bd4:ea79 with SMTP id m8-20020a170902db0800b001a06bd4ea79mr6398792plx.58.1679019810360; Thu, 16 Mar 2023 19:23:30 -0700 (PDT) X-Google-Smtp-Source: AK7set8NWXeWHMNleZ5qEuIyox3ywSOedR6rpdiiMbfhDTlWEzbV07tmNl/6ZZ+TkLNZPUmUi9fy/g== X-Received: by 2002:a17:902:db08:b0:1a0:6bd4:ea79 with SMTP id m8-20020a170902db0800b001a06bd4ea79mr6398774plx.58.1679019810007; Thu, 16 Mar 2023 19:23:30 -0700 (PDT) Received: from chengendu.. (111-248-125-11.dynamic-ip.hinet.net. [111.248.125.11]) by smtp.gmail.com with ESMTPSA id j10-20020a63fc0a000000b00503000f0492sm318553pgi.14.2023.03.16.19.23.29 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 16 Mar 2023 19:23:29 -0700 (PDT) From: Chengen Du To: kernel-team@lists.ubuntu.com Subject: [SRU][Lunar][PATCH 1/1] NFS: Correct timing for assigning access cache timestamp Date: Fri, 17 Mar 2023 10:23:26 +0800 Message-Id: <20230317022326.25526-2-chengen.du@canonical.com> X-Mailer: git-send-email 2.37.2 In-Reply-To: <20230317022326.25526-1-chengen.du@canonical.com> References: <20230317022326.25526-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 f7e4a88d5d92..e28dd6475e39 100644 --- a/fs/nfs/dir.c +++ b/fs/nfs/dir.c @@ -3089,7 +3089,6 @@ static void nfs_access_add_rbtree(struct inode *inode, 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); @@ -3114,6 +3113,7 @@ void nfs_access_add_cache(struct inode *inode, struct nfs_access_entry *set, cache->fsgid = cred->fsgid; cache->group_info = get_group_info(cred->group_info); 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