From patchwork Thu Mar 30 18:27:08 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tim Gardner X-Patchwork-Id: 1763396 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=rOtq4SNy; 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 4PnX2l6WL2z1yZ2 for ; Fri, 31 Mar 2023 05:27:27 +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 1phwza-0003Ms-2k; Thu, 30 Mar 2023 18:27:22 +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 1phwzX-0003Kv-ET for kernel-team@lists.ubuntu.com; Thu, 30 Mar 2023 18:27:19 +0000 Received: from mail-pl1-f200.google.com (mail-pl1-f200.google.com [209.85.214.200]) (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 1D9B03F235 for ; Thu, 30 Mar 2023 18:27:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1680200837; bh=pe/wON4mwqyex8sSkr2KYzCkAUDMbw3kGh7QMFYjuvY=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=rOtq4SNy0qrOgy6p0O+oMl8bdFeOtB9u7Z6n6OKhWzrUYPZQr6Xm3SEI2m8bl5IYd tByxdvfrPqYURWK4ng74QDSC6GHGRxcromAej8vLPKZWI4z5u2FJ+2QnVo2xHMeVZV uXQLH0N1qCrR2Qk6BYs2axgY/8jdSUHdO3dT0WhnKoAtFPEBfwsLwjNv1tb9jWPLWz xdha5PLaUVXoeOZ/tA3IRfLf4/3XhRTKO0jI3M9FWyhfpfHY1hhEpJlWP2nYsm+c0A lSJ4DGZ/zSfQ6tRF4yD6aiUO/DuRXi2/u5IPIpYr7/hIdTemS1wMO4YxREfm1q+0tN 9INYQ26tm2kSw== Received: by mail-pl1-f200.google.com with SMTP id w14-20020a170902e88e00b001a238a5946cso9076928plg.11 for ; Thu, 30 Mar 2023 11:27:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680200835; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=pe/wON4mwqyex8sSkr2KYzCkAUDMbw3kGh7QMFYjuvY=; b=wOxAuMhUGGwd5keH1jPmvDVmHtL+21iFB6asj2M5wUfUfU8895TDG1FLVwcn6Vy78X hmNVQcVHLJphI6xUeiKYQGgcSkDSdPzZ2FhlykJEJN52Nb/z1Q5Y0Lrxlovom6JS0uD3 EN5tEZsxgmTOVW9ToDaHfNUUidmx461mGEGkkXAvcMT7XoPezt82w+cDGdNDeFVQc2yv KvEETb2p3wI9sBKkbIjSUnKs37Fx6qdLWoRc0mR/fedqBH39NkyDaViU5TmH0oVUwbl3 hmg3QPInXv1gQFwJsaaEAs1humONTfYV0enH7rVqETxFqCSnA/YANi/lN5g6KkyGvWLV t4Gg== X-Gm-Message-State: AAQBX9chzxsmAHIVYWjGPgTVkDYsMjQ7PW8X92V6VSm0i0VytFOGkFR8 pcY615Iyzd8sPyc4e2NRQsmKW6LBvdlfoarh39lMMIqRyHcDJv2FPI6jkRxybQ5uPG8UiNspO+l JGyl66e1MhM582/HKrRXHAUejUJgOKzjPQ0pfzuK2Uk9hYq4Jfg== X-Received: by 2002:a62:5fc2:0:b0:627:fc31:1de with SMTP id t185-20020a625fc2000000b00627fc3101demr20690161pfb.7.1680200834968; Thu, 30 Mar 2023 11:27:14 -0700 (PDT) X-Google-Smtp-Source: AKy350Z/X3jijVhKOZjlAF8emmb5kOrPeKggXG4+tmp/yVd9+XEl7vYXquUoIFM1EZAZOUNKZjB7wg== X-Received: by 2002:a62:5fc2:0:b0:627:fc31:1de with SMTP id t185-20020a625fc2000000b00627fc3101demr20690152pfb.7.1680200834631; Thu, 30 Mar 2023 11:27:14 -0700 (PDT) Received: from smtp.gmail.com ([69.163.84.166]) by smtp.gmail.com with ESMTPSA id d19-20020aa78e53000000b005d61829db4fsm179375pfr.168.2023.03.30.11.27.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 30 Mar 2023 11:27:14 -0700 (PDT) From: Tim Gardner To: kernel-team@lists.ubuntu.com Subject: [PATCH 1/3] smb3: allow deferred close timeout to be configurable Date: Thu, 30 Mar 2023 12:27:08 -0600 Message-Id: <20230330182710.1141816-2-tim.gardner@canonical.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230330182710.1141816-1-tim.gardner@canonical.com> References: <20230330182710.1141816-1-tim.gardner@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: Steve French BugLink: https://bugs.launchpad.net/bugs/2013349 Deferred close can be a very useful feature for allowing caching data for read, and for minimizing the number of reopens needed for a file that is repeatedly opened and close but there are workloads where its default (1 second, similar to actimeo/acregmax) is much too small. Allow the user to configure the amount of time we can defer sending the final smb3 close when we have a handle lease on the file (rather than forcing it to depend on value of actimeo which is often unrelated, and less safe). Adds new mount parameter "closetimeo=" which is the maximum number of seconds we can wait before sending an SMB3 close when we have a handle lease for it. Default value also is set to slightly larger at 5 seconds (although some other clients use larger default this should still help). Suggested-by: Bharath SM Reviewed-by: Bharath SM Reviewed-by: Shyam Prasad N Reviewed-by: Paulo Alcantara (SUSE) Signed-off-by: Steve French (cherry picked from commit 5efdd9122eff772eae2feae9f0fc0ec02d4846a3) Signed-off-by: Tim Gardner --- fs/cifs/cifsfs.c | 1 + fs/cifs/connect.c | 2 ++ fs/cifs/file.c | 4 ++-- fs/cifs/fs_context.c | 9 +++++++++ fs/cifs/fs_context.h | 8 ++++++++ 5 files changed, 22 insertions(+), 2 deletions(-) diff --git a/fs/cifs/cifsfs.c b/fs/cifs/cifsfs.c index 2b68090c1d26..4eee2c2f0248 100644 --- a/fs/cifs/cifsfs.c +++ b/fs/cifs/cifsfs.c @@ -693,6 +693,7 @@ cifs_show_options(struct seq_file *s, struct dentry *root) seq_printf(s, ",acdirmax=%lu", cifs_sb->ctx->acdirmax / HZ); seq_printf(s, ",acregmax=%lu", cifs_sb->ctx->acregmax / HZ); } + seq_printf(s, ",closetimeo=%lu", cifs_sb->ctx->closetimeo / HZ); if (tcon->ses->chan_max > 1) seq_printf(s, ",multichannel,max_channels=%zu", diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c index 81f187af6aee..b746abd9556f 100644 --- a/fs/cifs/connect.c +++ b/fs/cifs/connect.c @@ -2629,6 +2629,8 @@ compare_mount_options(struct super_block *sb, struct cifs_mnt_data *mnt_data) return 0; if (old->ctx->acdirmax != new->ctx->acdirmax) return 0; + if (old->ctx->closetimeo != new->ctx->closetimeo) + return 0; return 1; } diff --git a/fs/cifs/file.c b/fs/cifs/file.c index 2e17624787da..ef599adff042 100644 --- a/fs/cifs/file.c +++ b/fs/cifs/file.c @@ -897,12 +897,12 @@ int cifs_close(struct inode *inode, struct file *file) * So, Increase the ref count to avoid use-after-free. */ if (!mod_delayed_work(deferredclose_wq, - &cfile->deferred, cifs_sb->ctx->acregmax)) + &cfile->deferred, cifs_sb->ctx->closetimeo)) cifsFileInfo_get(cfile); } else { /* Deferred close for files */ queue_delayed_work(deferredclose_wq, - &cfile->deferred, cifs_sb->ctx->acregmax); + &cfile->deferred, cifs_sb->ctx->closetimeo); cfile->deferred_close_scheduled = true; spin_unlock(&cinode->deferred_lock); return 0; diff --git a/fs/cifs/fs_context.c b/fs/cifs/fs_context.c index 8dc0d923ef6a..0e13dec86b25 100644 --- a/fs/cifs/fs_context.c +++ b/fs/cifs/fs_context.c @@ -147,6 +147,7 @@ const struct fs_parameter_spec smb3_fs_parameters[] = { fsparam_u32("actimeo", Opt_actimeo), fsparam_u32("acdirmax", Opt_acdirmax), fsparam_u32("acregmax", Opt_acregmax), + fsparam_u32("closetimeo", Opt_closetimeo), fsparam_u32("echo_interval", Opt_echo_interval), fsparam_u32("max_credits", Opt_max_credits), fsparam_u32("handletimeout", Opt_handletimeout), @@ -1074,6 +1075,13 @@ static int smb3_fs_context_parse_param(struct fs_context *fc, } ctx->acdirmax = ctx->acregmax = HZ * result.uint_32; break; + case Opt_closetimeo: + ctx->closetimeo = HZ * result.uint_32; + if (ctx->closetimeo > SMB3_MAX_DCLOSETIMEO) { + cifs_errorf(fc, "closetimeo too large\n"); + goto cifs_parse_mount_err; + } + break; case Opt_echo_interval: ctx->echo_interval = result.uint_32; break; @@ -1521,6 +1529,7 @@ int smb3_init_fs_context(struct fs_context *fc) ctx->acregmax = CIFS_DEF_ACTIMEO; ctx->acdirmax = CIFS_DEF_ACTIMEO; + ctx->closetimeo = SMB3_DEF_DCLOSETIMEO; /* Most clients set timeout to 0, allows server to use its default */ ctx->handle_timeout = 0; /* See MS-SMB2 spec section 2.2.14.2.12 */ diff --git a/fs/cifs/fs_context.h b/fs/cifs/fs_context.h index 5f093cb7e9b9..bbaee4c2281f 100644 --- a/fs/cifs/fs_context.h +++ b/fs/cifs/fs_context.h @@ -125,6 +125,7 @@ enum cifs_param { Opt_actimeo, Opt_acdirmax, Opt_acregmax, + Opt_closetimeo, Opt_echo_interval, Opt_max_credits, Opt_snapshot, @@ -247,6 +248,8 @@ struct smb3_fs_context { /* attribute cache timemout for files and directories in jiffies */ unsigned long acregmax; unsigned long acdirmax; + /* timeout for deferred close of files in jiffies */ + unsigned long closetimeo; struct smb_version_operations *ops; struct smb_version_values *vals; char *prepath; @@ -279,4 +282,9 @@ static inline struct smb3_fs_context *smb3_fc2context(const struct fs_context *f extern int smb3_fs_context_dup(struct smb3_fs_context *new_ctx, struct smb3_fs_context *ctx); extern void smb3_update_mnt_flags(struct cifs_sb_info *cifs_sb); +/* + * max deferred close timeout (jiffies) - 2^30 + */ +#define SMB3_MAX_DCLOSETIMEO (1 << 30) +#define SMB3_DEF_DCLOSETIMEO (5 * HZ) /* Can increase later, other clients use larger */ #endif From patchwork Thu Mar 30 18:27:09 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tim Gardner X-Patchwork-Id: 1763394 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=KUMbjSz/; 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 4PnX2l0d6bz1yZ0 for ; Fri, 31 Mar 2023 05:27:26 +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 1phwzY-0003LW-KK; Thu, 30 Mar 2023 18:27:20 +0000 Received: from smtp-relay-internal-0.internal ([10.131.114.225] helo=smtp-relay-internal-0.canonical.com) by huckleberry.canonical.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1phwzV-0003KY-LN for kernel-team@lists.ubuntu.com; Thu, 30 Mar 2023 18:27:17 +0000 Received: from mail-pj1-f70.google.com (mail-pj1-f70.google.com [209.85.216.70]) (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-0.canonical.com (Postfix) with ESMTPS id 606DF3F236 for ; Thu, 30 Mar 2023 18:27:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1680200837; bh=B/Y5o5YcQPli323bUBbz2aGavoLcqXqrZhjvq1VGh10=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=KUMbjSz/Uvi0k4WGhOoqNwNffckp5L5L/HZIPZuESYDcD9LGe2w7xShM3UzedzBoV DqMc1707AJW5OXTKFQD1L5kjEt0YoTBguuJIIwoXpkeZvQSHJg25yeDckgRJ5dKX5u 7wOGPGeVf5YOmbHXTQnbNAgfgZfQmGre71FVbOUYfVUSLIrITvRe4c1VaxZeNxO2hv HE/YsRmKyj3pRLxk48tlvZiKqWZvfoKSH/GDJNLEj7CgMjs4bg6Df3ofxk6MkooiSe +LvHjBKwH6FqdVCwauRxkLY8fLKSkl3NrTAYMj6fRmDtxX81BHTYNCDiRRfe27URl+ QfkZLEHTPVR/w== Received: by mail-pj1-f70.google.com with SMTP id gj9-20020a17090b108900b0024038c818a0so6204893pjb.7 for ; Thu, 30 Mar 2023 11:27:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680200835; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=B/Y5o5YcQPli323bUBbz2aGavoLcqXqrZhjvq1VGh10=; b=r3sWxh4urSlhfsKxJUYG9MSzx5/2Z1ReryF6r40vWPq3vjm6HBQLtXmYGD9LZ9q6Ou 5yAkgYWvP96VSz5VaIUBvhMxeQpvL12s+gHkuWWwCshuCviVLbpLqHPz8k0WxEvWaOQO ngEhwOEFvonJbdl01xs1Ptw34th0coyTO6ZSQ56z1mXwEcYVrtfF3uJj0oZ2sRiqbeiR +BZN75jiFU9aaoJfAAJZVCSWzBfjHM0VFCtzl5NTbpEUPEoJcgSHM1VumlfC/qPYvKhf vhQXJUBYla6eBFPIP2A5jpqFXVcKF+geplz/i++rfZiws0DFGOZMBMiNe3dMKXx0d1qX zc+Q== X-Gm-Message-State: AO0yUKVa25vG3Tf5shZ1jp27ZNb3tf+2WgU56YbtvPAptzPS62a0Dtk+ CBJlVg1F1fX63ndwh16VHIAeBJ0BiG0idxxyAkZmMWV6NQx/0bsoes+cLgNVLIKZS1unmL8oTPN sDp7QwXF7XgnOpdJ81M9iKAjMIIyKBpWmigWnF9FpM5/XnhBN1A== X-Received: by 2002:a05:6a20:af1c:b0:d9:3683:bc15 with SMTP id dr28-20020a056a20af1c00b000d93683bc15mr19799406pzb.19.1680200835650; Thu, 30 Mar 2023 11:27:15 -0700 (PDT) X-Google-Smtp-Source: AK7set/JF9DYTiOnL+gFDkA2JzPl5+/APl2g30/nTuAYBBBEi339z0ZZ/Q/hzA2YT6Z3yX8LrPyyKg== X-Received: by 2002:a05:6a20:af1c:b0:d9:3683:bc15 with SMTP id dr28-20020a056a20af1c00b000d93683bc15mr19799388pzb.19.1680200835367; Thu, 30 Mar 2023 11:27:15 -0700 (PDT) Received: from smtp.gmail.com ([69.163.84.166]) by smtp.gmail.com with ESMTPSA id d19-20020aa78e53000000b005d61829db4fsm179375pfr.168.2023.03.30.11.27.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 30 Mar 2023 11:27:15 -0700 (PDT) From: Tim Gardner To: kernel-team@lists.ubuntu.com Subject: [PATCH 2/3] smb3: lower default deferred close timeout to address perf regression Date: Thu, 30 Mar 2023 12:27:09 -0600 Message-Id: <20230330182710.1141816-3-tim.gardner@canonical.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230330182710.1141816-1-tim.gardner@canonical.com> References: <20230330182710.1141816-1-tim.gardner@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: Steve French BugLink: https://bugs.launchpad.net/bugs/2013349 Performance tests with large number of threads noted that the change of the default closetimeo (deferred close timeout between when close is done by application and when client has to send the close to the server), to 5 seconds from 1 second, significantly degraded perf in some cases like this (in the filebench example reported, the stats show close requests on the wire taking twice as long, and 50% regression in filebench perf). This is stil configurable via mount parm closetimeo, but to be safe, decrease default back to its previous value of 1 second. Reported-by: Yin Fengwei Reported-by: kernel test robot Link: https://lore.kernel.org/lkml/997614df-10d4-af53-9571-edec36b0e2f3@intel.com/ Fixes: 5efdd9122eff ("smb3: allow deferred close timeout to be configurable") Cc: stable@vger.kernel.org # 6.0+ Tested-by: Yin Fengwei Reviewed-by: Paulo Alcantara (SUSE) Reviewed-by: Shyam Prasad N Signed-off-by: Steve French (cherry picked from commit 7e0e76d99079be13c9961dde7c93b2d1ee665af4) Signed-off-by: Tim Gardner --- fs/cifs/fs_context.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/cifs/fs_context.h b/fs/cifs/fs_context.h index bbaee4c2281f..a268896d05d5 100644 --- a/fs/cifs/fs_context.h +++ b/fs/cifs/fs_context.h @@ -286,5 +286,5 @@ extern void smb3_update_mnt_flags(struct cifs_sb_info *cifs_sb); * max deferred close timeout (jiffies) - 2^30 */ #define SMB3_MAX_DCLOSETIMEO (1 << 30) -#define SMB3_DEF_DCLOSETIMEO (5 * HZ) /* Can increase later, other clients use larger */ +#define SMB3_DEF_DCLOSETIMEO (1 * HZ) /* even 1 sec enough to help eg open/write/close/open/read */ #endif From patchwork Thu Mar 30 18:27:10 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tim Gardner X-Patchwork-Id: 1763397 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=p8a/BgQj; 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 4PnX2l17Pjz1yZ1 for ; Fri, 31 Mar 2023 05:27:26 +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 1phwzY-0003Lq-SG; Thu, 30 Mar 2023 18:27:20 +0000 Received: from smtp-relay-internal-0.internal ([10.131.114.225] helo=smtp-relay-internal-0.canonical.com) by huckleberry.canonical.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1phwzW-0003Ku-KR for kernel-team@lists.ubuntu.com; Thu, 30 Mar 2023 18:27:18 +0000 Received: from mail-pf1-f199.google.com (mail-pf1-f199.google.com [209.85.210.199]) (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-0.canonical.com (Postfix) with ESMTPS id 4F91F3F236 for ; Thu, 30 Mar 2023 18:27:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1680200838; bh=CJ1PElOlMt7y7unR3oO2rWOLaMVgGC83lO7Imr8nUVA=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=p8a/BgQjSQk7deBRewHpAx0RSWKhBnPOcuD/ltGRCDd8qHw6QHF2RS8DvRILGQ2fi uY8WJ6BnaGV46+FQE80oAFShxhSFfh+0+aEOlwrDx1UON4F9BHx+uXEA4nXVekeEJ6 Sj2ntUqG5Sn2tt/qLSM0npHTwOwZiANS5ZhRXw+x6dyyiDpULXNTJvtp8PdciI7AKI f5dXrDLKPfCVVU9sAzp3C/ieJc8uHOHyJr2Qjgc5SzjjhpBAVd6rQa/RcVWCNR61Cy IaQOtN/Qnvrjyq9SIYx/x1B/yRPtEw6C5d792x+Q5dFBhbLGnzBGkQmGa2BssyssK2 7tX/KjNl8qQLQ== Received: by mail-pf1-f199.google.com with SMTP id t67-20020a628146000000b0062d6d838243so6851189pfd.21 for ; Thu, 30 Mar 2023 11:27:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680200836; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=CJ1PElOlMt7y7unR3oO2rWOLaMVgGC83lO7Imr8nUVA=; b=J5pnfQ4CQFc28oKrl4PX/m3usd6nyZSSBH5cdsHIx8hb77X8TyYeuHj9u2CyHMnLrB hPwOsuV/L9H1jCxwXoJsqpYh4UQasWVmxKfQuXDIyI3RI4gkOIbHRR4W+2TrdlonmwiB jC40hwR8Uid0MYlYxpkx6fiokLTl4668YyDUM9Z6Aw2G0IKkfe78u0lZ+BauTbmR/0UC XVg8UEZYoqdVaI5m8edgSegohddqCQK42h0gHmGVlqrO2RcAg21ySzvS/In9ME9Czw7P WGLKHJ1cf3CtLwSJ/jpVf+Q9x8i/yiElMriJ9IZX2niaoGmJmhTHTqNgycosQEKTdn29 21uw== X-Gm-Message-State: AAQBX9etp+Osp8U2NRj2NBg2Plk841BumKYxjoZrt5vQnG8/JOeV65Oe id0bmkyEzgK535+jbgs2cAt3jG2/IQgN91Y7zciPSaDnsA2suQmPOeeuBdV01CSm8vhoU+uy6bJ mPPW8pbpzv47xiPN/xU7o5Hq5DiBn2Ypk9wQaUuspmzYWfU2Snw== X-Received: by 2002:a62:7b10:0:b0:625:c048:2f81 with SMTP id w16-20020a627b10000000b00625c0482f81mr23063552pfc.32.1680200836402; Thu, 30 Mar 2023 11:27:16 -0700 (PDT) X-Google-Smtp-Source: AKy350YocU1uawVlZiF8iSci2aDWh5D+2jZ/+hg1ZKdbu7FGQ2KXlW3xSPSrrX9kqK2gzSm0TUlgdA== X-Received: by 2002:a62:7b10:0:b0:625:c048:2f81 with SMTP id w16-20020a627b10000000b00625c0482f81mr23063539pfc.32.1680200836133; Thu, 30 Mar 2023 11:27:16 -0700 (PDT) Received: from smtp.gmail.com ([69.163.84.166]) by smtp.gmail.com with ESMTPSA id d19-20020aa78e53000000b005d61829db4fsm179375pfr.168.2023.03.30.11.27.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 30 Mar 2023 11:27:15 -0700 (PDT) From: Tim Gardner To: kernel-team@lists.ubuntu.com Subject: [PATCH 3/3] keys: Do not cache key in task struct if key is requested from kernel thread Date: Thu, 30 Mar 2023 12:27:10 -0600 Message-Id: <20230330182710.1141816-4-tim.gardner@canonical.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230330182710.1141816-1-tim.gardner@canonical.com> References: <20230330182710.1141816-1-tim.gardner@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: David Howells BugLink: https://bugs.launchpad.net/bugs/2013349 The key which gets cached in task structure from a kernel thread does not get invalidated even after expiry. Due to which, a new key request from kernel thread will be served with the cached key if it's present in task struct irrespective of the key validity. The change is to not cache key in task_struct when key requested from kernel thread so that kernel thread gets a valid key on every key request. The problem has been seen with the cifs module doing DNS lookups from a kernel thread and the results getting pinned by being attached to that kernel thread's cache - and thus not something that can be easily got rid of. The cache would ordinarily be cleared by notify-resume, but kernel threads don't do that. This isn't seen with AFS because AFS is doing request_key() within the kernel half of a user thread - which will do notify-resume. Fixes: 7743c48e54ee ("keys: Cache result of request_key*() temporarily in task_struct") Signed-off-by: Bharath SM Signed-off-by: David Howells Reviewed-by: Jarkko Sakkinen cc: Shyam Prasad N cc: Steve French cc: keyrings@vger.kernel.org cc: linux-cifs@vger.kernel.org cc: linux-fsdevel@vger.kernel.org Link: https://lore.kernel.org/r/CAGypqWw951d=zYRbdgNR4snUDvJhWL=q3=WOyh7HhSJupjz2vA@mail.gmail.com/ (cherry picked from commit 47f9e4c924025c5be87959d3335e66fcbb7f6b5c) Signed-off-by: Tim Gardner --- security/keys/request_key.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/security/keys/request_key.c b/security/keys/request_key.c index 2da4404276f0..07a0ef2baacd 100644 --- a/security/keys/request_key.c +++ b/security/keys/request_key.c @@ -38,9 +38,12 @@ static void cache_requested_key(struct key *key) #ifdef CONFIG_KEYS_REQUEST_CACHE struct task_struct *t = current; - key_put(t->cached_requested_key); - t->cached_requested_key = key_get(key); - set_tsk_thread_flag(t, TIF_NOTIFY_RESUME); + /* Do not cache key if it is a kernel thread */ + if (!(t->flags & PF_KTHREAD)) { + key_put(t->cached_requested_key); + t->cached_requested_key = key_get(key); + set_tsk_thread_flag(t, TIF_NOTIFY_RESUME); + } #endif }