Message ID | 168980892326.1619861.2405779251348138586.stgit@bmoger-ubuntu |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:c923:0:b0:3e4:2afc:c1 with SMTP id j3csp2774237vqt; Wed, 19 Jul 2023 16:34:36 -0700 (PDT) X-Google-Smtp-Source: APBJJlFlfy64LGdWeoHYQMdPvms/f+ZlLGMfiOJnwAQaUZZZIHaiWX9+Nvcq+uaAaxDKljVuwJ1U X-Received: by 2002:a05:6512:39d3:b0:4f8:49a8:a0e2 with SMTP id k19-20020a05651239d300b004f849a8a0e2mr387401lfu.16.1689809676498; Wed, 19 Jul 2023 16:34:36 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1689809676; cv=pass; d=google.com; s=arc-20160816; b=sy9u6OD28AP4ZwUlxAnP/IFUl8YRBUSCvON+gyEpBzkTEaSqd5dM/v5UDi2Em48kDK BP/a2biQgI6fM+jWw+MPMov8IHJxpensFu+Qr2DOChHsu96wpnv5V/995C9rZhLeEqJ8 xSvGYr2ekBSMcOhmgJbmVf/shytmZSA7AlGSnbauTpGyVz2UxOo/k6DX48NAbLMv9EC7 oR4Y5/waZzMyk41Yzk7OX9M49zfl7F+S/aIh/c0AfJ0RuJs/ZKCV9lKZTo/uZh8ev3by LQRqURcJlQqN6x18e662NgKn1SXcHYksbv//0M09CDRJKvOkFyGKen0mmiIPZz7hPXKd BIXQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:cc:to:from :subject:dkim-signature; bh=Th6/t3mREpZEsSW4UhPaIsUf+aPY0ugCbYGGZAF13nI=; fh=h28vckfI3GX5WFto8VbLoaUMI0xqlhwXGWb2ZADi/Dw=; b=kpwKWb/kLJkB3XhmF3eVQCc5ea8OIo4FsRM1GwW7/2KXVXs6+JDx1wH+nTpm0XVpxd +yZBTYbef8tg97p6jnBtrS75hdxhG9vgC99GNAgTiIXx7iVsrK2ghaPOv2XFgPhY+enF 4AUj8cEKZvO2oeYiIu2bvynOihLK3gJQ6FMXKmpYBcsp6kYP/MZlpyYffvfbaaGQ+d9V VIq6e79vRUfoSQliujNlljZfkr9OAxX+Oilg9QY4GRRS4sJtFmRKzwVu49RaZK/vhXrA 3SiLdAQqVfgXgDmJsiOeN6JYJoq/jJVLJAt1WbVPyMBaWBIAICwtZMZnYtv9Qd/OtGNA hTmQ== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@amd.com header.s=selector1 header.b=RgXEcUug; arc=pass (i=1 spf=pass spfdomain=amd.com dmarc=pass fromdomain=amd.com); spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=amd.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id l25-20020aa7c3d9000000b0051dd1d7fbeasi3605013edr.683.2023.07.19.16.34.12; Wed, 19 Jul 2023 16:34:36 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-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=@amd.com header.s=selector1 header.b=RgXEcUug; arc=pass (i=1 spf=pass spfdomain=amd.com dmarc=pass fromdomain=amd.com); spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=amd.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230245AbjGSXW2 (ORCPT <rfc822;daweilics@gmail.com> + 99 others); Wed, 19 Jul 2023 19:22:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35104 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230268AbjGSXWZ (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 19 Jul 2023 19:22:25 -0400 Received: from NAM04-DM6-obe.outbound.protection.outlook.com (mail-dm6nam04on2083.outbound.protection.outlook.com [40.107.102.83]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D2F43268D; Wed, 19 Jul 2023 16:22:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lAehErivdl0MnBQQuBctUXbMWuJqMmkPP/sR4EN3R7QUOaJzo1QXm61nzjMXk/DrDyQXW94OlSQfZpZ3Jr8t9AymupHQE6ZIvxf5A4vF7doIi8qcEf9zoe2PdK//yv/H63cO7DLku/hV7QCK+TTxdaGhuxLqm0jkGsBdcW/LDLPF1e7kkpjrGwY6Nw6ZylqsOwwbAuCsIcN91gBpFGeWlHEtz+Y4IrNQ6u1IlUgRjDEsPYJrJJe2Q8HCe4y7CNOjW6WZFLVKp52JLABc6YT//J23liM5MZswiIpKss+AwA67d/ZEFpoMGMGlvHqDJaXQcSJI9EOjutg2c5UWBoITIA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Th6/t3mREpZEsSW4UhPaIsUf+aPY0ugCbYGGZAF13nI=; b=g7LsqhF5foAb2VUYNroKt7PHpuT4hwsMO9G1vPWAislrBoWGlJlyQv4VutFzSodKyj3+XA9100jL3nXZMC2Z+xMyvXbX1In3nS4YwOYReMws9umAtIlYSGSlrqoZBrjlYFpNpht92AV62jIfWYQ13xLpON8qi8nJAcV5t29BEuWwYQtHa1Ji4e4biWz6+MYIAKVvTSgUpgXORBUlB+gnOg9PfKszyfHmKG/t/JPdOtJllE1Uv+66R7L0Q8kBkVZfZnIvzxmLEcT+cDN6RkDrui92HHPS2EHLUCnk0gUcrtcB57LgNYclRtzX38Tefi5/+ok9vhKL4vcUMD6dAKcmew== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=kernel.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Th6/t3mREpZEsSW4UhPaIsUf+aPY0ugCbYGGZAF13nI=; b=RgXEcUugFTlIPxzQq2rcerrioJIW83v7Utn1ZZzsObrgojD2p5lVpiUk8OIux6Xp1JsQvIaMFvzVY8IunqZJLMBOhXiQugy0zxjiguY1SGxQqt+RDMT0JQsfcYYiuKhwdsATv19p5r4UlG1FqXGjNZcLvpREdTVs6Gp6Xv6najU= Received: from DM6PR02CA0062.namprd02.prod.outlook.com (2603:10b6:5:177::39) by DM4PR12MB5231.namprd12.prod.outlook.com (2603:10b6:5:39b::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6609.23; Wed, 19 Jul 2023 23:22:07 +0000 Received: from DM6NAM11FT051.eop-nam11.prod.protection.outlook.com (2603:10b6:5:177:cafe::1c) by DM6PR02CA0062.outlook.office365.com (2603:10b6:5:177::39) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6609.24 via Frontend Transport; Wed, 19 Jul 2023 23:22:07 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C Received: from SATLEXMB04.amd.com (165.204.84.17) by DM6NAM11FT051.mail.protection.outlook.com (10.13.172.243) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.6588.34 via Frontend Transport; Wed, 19 Jul 2023 23:22:07 +0000 Received: from [127.0.1.1] (10.180.168.240) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.23; Wed, 19 Jul 2023 18:22:04 -0500 Subject: [PATCH v6 5/8] x86/resctrl: Unwind the errors inside rdt_enable_ctx From: Babu Moger <babu.moger@amd.com> To: <corbet@lwn.net>, <reinette.chatre@intel.com>, <tglx@linutronix.de>, <mingo@redhat.com>, <bp@alien8.de> CC: <fenghua.yu@intel.com>, <dave.hansen@linux.intel.com>, <x86@kernel.org>, <hpa@zytor.com>, <paulmck@kernel.org>, <akpm@linux-foundation.org>, <quic_neeraju@quicinc.com>, <rdunlap@infradead.org>, <damien.lemoal@opensource.wdc.com>, <songmuchun@bytedance.com>, <peterz@infradead.org>, <jpoimboe@kernel.org>, <pbonzini@redhat.com>, <babu.moger@amd.com>, <chang.seok.bae@intel.com>, <pawan.kumar.gupta@linux.intel.com>, <jmattson@google.com>, <daniel.sneddon@linux.intel.com>, <sandipan.das@amd.com>, <tony.luck@intel.com>, <james.morse@arm.com>, <linux-doc@vger.kernel.org>, <linux-kernel@vger.kernel.org>, <bagasdotme@gmail.com>, <eranian@google.com>, <christophe.leroy@csgroup.eu>, <pawan.kumar.gupta@linux.intel.com>, <jarkko@kernel.org>, <adrian.hunter@intel.com>, <quic_jiles@quicinc.com>, <peternewman@google.com>, <babu.moger@amd.com> Date: Wed, 19 Jul 2023 18:22:03 -0500 Message-ID: <168980892326.1619861.2405779251348138586.stgit@bmoger-ubuntu> In-Reply-To: <168980872063.1619861.420806535295905172.stgit@bmoger-ubuntu> References: <168980872063.1619861.420806535295905172.stgit@bmoger-ubuntu> User-Agent: StGit/1.1.dev103+g5369f4c MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com (10.181.40.145) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DM6NAM11FT051:EE_|DM4PR12MB5231:EE_ X-MS-Office365-Filtering-Correlation-Id: cac4c581-50c2-4519-b385-08db88aef86f X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: LQHIaSHsrAzt2Lt+PNg6amcJX6kxOmTc8Wf817vCRAkC4s255yLHX26qvOK7Lb3S8On1GaUjgzzRiNxYIqzmKE9Q+BwHaRJCcg4YPn2k6aOZdfMukqzlu06IR0ABB43skT6kS36gyMRgDxj7ZAsPDdT7SHcZ0A0lhZQAAC9e0YCj+MPJWXiW8h2TTSn4sQ0owotR/0Q0IFIFCByIiKSMDXl7/mbvtooI+l5vcnpu8iABb3z+r55JCKBqJINbpC04cKkhyNtBD/deN3UqbaPiP119KGE1xXqAdPee4MX12hZYIwxrkTNTHAegmPklGH8tsM3HSIl44L2xgGc10xMFyubiLXuG0SBVoNaVPbU09DtJMuxohQYbES5bgjaNufPgjiqyG5YywqIYyCeiBiDBm7OyDryiBmDzQGSvT0Os7epulshujQKc3Bgwx/MIR73BL3w8H1NpMiQQiMp/6NQE5aRP+r6GNSMe3U+J9EwxFVP3cbEECKF85pNzNKyw+NH8r1EzOi4uZDxvkoC+uIzdUcuQ91Hyz1iv+HkObTC74dCCsWyysHnrA4+/SqmkVs3V/85G1lyP1hLquiPZX+6nPY9TH7YchQqv5YI0OsLTN5BS+XuOHEG6pUHuXwOGIzIHjDgnD7HtvuMq7V7YS+cLrgW7GgIbE0PXurBg6AKjvLyjAoIoHffOsbh9p0Dnuv7o/K0lf1PuPYaWvboRg9Mpm0zZgzA4k55Ih+8747hS8Jmg0I2SYI0fP9hetnqbzoIAz0o1lUBqHJkdZYxv8Oo9LV/PxQU9bCXFhSSy5eiM1SA= X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230028)(7916004)(4636009)(346002)(396003)(376002)(39860400002)(136003)(451199021)(82310400008)(40470700004)(36840700001)(46966006)(103116003)(16526019)(110136005)(478600001)(54906003)(186003)(26005)(336012)(9686003)(83380400001)(2906002)(70586007)(33716001)(41300700001)(5660300002)(8936002)(7406005)(8676002)(40480700001)(44832011)(7416002)(16576012)(356005)(81166007)(82740400003)(70206006)(36860700001)(47076005)(426003)(86362001)(4326008)(316002)(66899021)(40460700003)(71626016)(36900700001);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Jul 2023 23:22:07.5720 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: cac4c581-50c2-4519-b385-08db88aef86f X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: DM6NAM11FT051.eop-nam11.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB5231 X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FORGED_SPF_HELO, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_NONE, T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=no 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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1771893871413867587 X-GMAIL-MSGID: 1771893871413867587 |
Series |
x86/resctrl: Miscellaneous resctrl features
|
|
Commit Message
Moger, Babu
July 19, 2023, 11:22 p.m. UTC
rdt_enable_ctx() takes care of enabling the features provided during
resctrl mount. The error unwinding of rdt_enable_ctx is done from the
caller rdt_get_tree. This is not ideal and can cause some error unwinding
to be omitted.
Fix this by moving all the error unwinding inside rdt_enable_ctx.
Suggested-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: Babu Moger <babu.moger@amd.com>
---
arch/x86/kernel/cpu/resctrl/rdtgroup.c | 31 +++++++++++++++++++++++--------
1 file changed, 23 insertions(+), 8 deletions(-)
Comments
Hi Babu, On 7/19/2023 4:22 PM, Babu Moger wrote: > rdt_enable_ctx() takes care of enabling the features provided during "rdt_enable_ctx() takes care of enabling" can just be "rdt_enable_ctx() enables" > resctrl mount. The error unwinding of rdt_enable_ctx is done from the > caller rdt_get_tree. This is not ideal and can cause some error unwinding > to be omitted. > Please consistently use () to indicate function names (in changelog and subject). "This is not ideal and can cause some error unwinding to be omitted." is a bit vague. How about (in a new paragraph): "Additions to rdt_enable_ctx() are required to also modify error paths of rdt_enable_ctx() callers to ensure correct unwinding if errors are encountered after calling rdt_enable_ctx(). This is error prone." > Fix this by moving all the error unwinding inside rdt_enable_ctx. "Fix" creates expectation for a "fixes" tag which is not needed here. This refactors code to simplify future additions. Even so, I do not think this solution addresses the stated problem (more below). > > Suggested-by: Reinette Chatre <reinette.chatre@intel.com> > Signed-off-by: Babu Moger <babu.moger@amd.com> > --- > arch/x86/kernel/cpu/resctrl/rdtgroup.c | 31 +++++++++++++++++++++++-------- > 1 file changed, 23 insertions(+), 8 deletions(-) > > diff --git a/arch/x86/kernel/cpu/resctrl/rdtgroup.c b/arch/x86/kernel/cpu/resctrl/rdtgroup.c > index 3010e3a1394d..9a7204f71d2d 100644 > --- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c > +++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c > @@ -2381,15 +2381,31 @@ static int rdt_enable_ctx(struct rdt_fs_context *ctx) > { > int ret = 0; > > - if (ctx->enable_cdpl2) > + if (ctx->enable_cdpl2) { > ret = resctrl_arch_set_cdp_enabled(RDT_RESOURCE_L2, true); > + if (ret) > + goto out; > + } > > - if (!ret && ctx->enable_cdpl3) > + if (ctx->enable_cdpl3) { > ret = resctrl_arch_set_cdp_enabled(RDT_RESOURCE_L3, true); > + if (ret) > + goto out_cdpl2; > + } > > - if (!ret && ctx->enable_mba_mbps) > + if (ctx->enable_mba_mbps) { > ret = set_mba_sc(true); > + if (ret) > + goto out_cdpl3; > + } > > + return 0; > + > +out_cdpl3: > + resctrl_arch_set_cdp_enabled(RDT_RESOURCE_L3, false); > +out_cdpl2: > + resctrl_arch_set_cdp_enabled(RDT_RESOURCE_L2, false); Be careful here. There is no dependency between L3 and L2 CDP ... if L3 CDP was enabled it does not mean that L2 CDP was enabled also. Similarly, if the software controller was enabled it does not mean that CDP was also enabled. Since resctrl_arch_set_cdp_enabled() does much more than just change a flag value I think these should first check if it was enabled before disabling the feature. > +out: > return ret; > } > > @@ -2497,13 +2513,13 @@ static int rdt_get_tree(struct fs_context *fc) > } > > ret = rdt_enable_ctx(ctx); > - if (ret < 0) > - goto out_cdp; > + if (ret) > + goto out; > > ret = schemata_list_create(); > if (ret) { > schemata_list_destroy(); > - goto out_mba; > + goto out_ctx; > } > > closid_init(); > @@ -2562,10 +2578,9 @@ static int rdt_get_tree(struct fs_context *fc) > kernfs_remove(kn_info); > out_schemata_free: > schemata_list_destroy(); > -out_mba: > +out_ctx: > if (ctx->enable_mba_mbps) > set_mba_sc(false); > -out_cdp: > cdp_disable_all(); > out: > rdt_last_cmd_clear(); > The problem statement in the changelog was that rdt_get_tree() is doing error unwinding of rdt_enable_ctx(). Looking at the above it seems that the problem remains ... callers of rdt_enable_ctx() still need to know all internals of that function to do error unwind correctly. Could it perhaps be made simpler with a new rdt_disable_ctx() that undoes rdt_enable_ctx()? New additions to rdt_enable_ctx() would have more clarity where changes are needed and callers only need to call a single rdt_disable_ctx(). Reinette
Hi Reinette, On 8/4/23 15:41, Reinette Chatre wrote: > Hi Babu, > > On 7/19/2023 4:22 PM, Babu Moger wrote: >> rdt_enable_ctx() takes care of enabling the features provided during > > "rdt_enable_ctx() takes care of enabling" can just be "rdt_enable_ctx() > enables" Sure. > >> resctrl mount. The error unwinding of rdt_enable_ctx is done from the >> caller rdt_get_tree. This is not ideal and can cause some error unwinding >> to be omitted. >> > > Please consistently use () to indicate function names (in > changelog and subject). Sure. > > "This is not ideal and can cause some error unwinding to be omitted." > is a bit vague. How about (in a new paragraph): > "Additions to rdt_enable_ctx() are required to also modify error paths > of rdt_enable_ctx() callers to ensure correct unwinding if errors > are encountered after calling rdt_enable_ctx(). This is error prone." Sure. > >> Fix this by moving all the error unwinding inside rdt_enable_ctx. > > "Fix" creates expectation for a "fixes" tag which is not needed here. This > refactors code to simplify future additions. Sure. > > Even so, I do not think this solution addresses the stated problem (more > below). > >> >> Suggested-by: Reinette Chatre <reinette.chatre@intel.com> >> Signed-off-by: Babu Moger <babu.moger@amd.com> >> --- >> arch/x86/kernel/cpu/resctrl/rdtgroup.c | 31 +++++++++++++++++++++++-------- >> 1 file changed, 23 insertions(+), 8 deletions(-) >> >> diff --git a/arch/x86/kernel/cpu/resctrl/rdtgroup.c b/arch/x86/kernel/cpu/resctrl/rdtgroup.c >> index 3010e3a1394d..9a7204f71d2d 100644 >> --- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c >> +++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c >> @@ -2381,15 +2381,31 @@ static int rdt_enable_ctx(struct rdt_fs_context *ctx) >> { >> int ret = 0; >> >> - if (ctx->enable_cdpl2) >> + if (ctx->enable_cdpl2) { >> ret = resctrl_arch_set_cdp_enabled(RDT_RESOURCE_L2, true); >> + if (ret) >> + goto out; >> + } >> >> - if (!ret && ctx->enable_cdpl3) >> + if (ctx->enable_cdpl3) { >> ret = resctrl_arch_set_cdp_enabled(RDT_RESOURCE_L3, true); >> + if (ret) >> + goto out_cdpl2; >> + } >> >> - if (!ret && ctx->enable_mba_mbps) >> + if (ctx->enable_mba_mbps) { >> ret = set_mba_sc(true); >> + if (ret) >> + goto out_cdpl3; >> + } >> >> + return 0; >> + >> +out_cdpl3: >> + resctrl_arch_set_cdp_enabled(RDT_RESOURCE_L3, false); >> +out_cdpl2: >> + resctrl_arch_set_cdp_enabled(RDT_RESOURCE_L2, false); > > Be careful here. There is no dependency between L3 and L2 CDP ... > if L3 CDP was enabled it does not mean that L2 CDP was enabled also. > Similarly, if the software controller was enabled it does not mean that > CDP was also enabled. > Since resctrl_arch_set_cdp_enabled() does much more than just change > a flag value I think these should first check if it was enabled > before disabling the feature. Yes. Agree. > >> +out: >> return ret; >> } >> >> @@ -2497,13 +2513,13 @@ static int rdt_get_tree(struct fs_context *fc) >> } >> >> ret = rdt_enable_ctx(ctx); >> - if (ret < 0) >> - goto out_cdp; >> + if (ret) >> + goto out; >> >> ret = schemata_list_create(); >> if (ret) { >> schemata_list_destroy(); >> - goto out_mba; >> + goto out_ctx; >> } >> >> closid_init(); >> @@ -2562,10 +2578,9 @@ static int rdt_get_tree(struct fs_context *fc) >> kernfs_remove(kn_info); >> out_schemata_free: >> schemata_list_destroy(); >> -out_mba: >> +out_ctx: >> if (ctx->enable_mba_mbps) >> set_mba_sc(false); >> -out_cdp: >> cdp_disable_all(); >> out: >> rdt_last_cmd_clear(); >> > > The problem statement in the changelog was that rdt_get_tree() is > doing error unwinding of rdt_enable_ctx(). Looking at the above it > seems that the problem remains ... callers of rdt_enable_ctx() > still need to know all internals of that function to do error > unwind correctly. Could it perhaps be made simpler with a new > rdt_disable_ctx() that undoes rdt_enable_ctx()? New additions > to rdt_enable_ctx() would have more clarity where changes are > needed and callers only need to call a single rdt_disable_ctx(). > Yes. We can do that.
diff --git a/arch/x86/kernel/cpu/resctrl/rdtgroup.c b/arch/x86/kernel/cpu/resctrl/rdtgroup.c index 3010e3a1394d..9a7204f71d2d 100644 --- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c +++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c @@ -2381,15 +2381,31 @@ static int rdt_enable_ctx(struct rdt_fs_context *ctx) { int ret = 0; - if (ctx->enable_cdpl2) + if (ctx->enable_cdpl2) { ret = resctrl_arch_set_cdp_enabled(RDT_RESOURCE_L2, true); + if (ret) + goto out; + } - if (!ret && ctx->enable_cdpl3) + if (ctx->enable_cdpl3) { ret = resctrl_arch_set_cdp_enabled(RDT_RESOURCE_L3, true); + if (ret) + goto out_cdpl2; + } - if (!ret && ctx->enable_mba_mbps) + if (ctx->enable_mba_mbps) { ret = set_mba_sc(true); + if (ret) + goto out_cdpl3; + } + return 0; + +out_cdpl3: + resctrl_arch_set_cdp_enabled(RDT_RESOURCE_L3, false); +out_cdpl2: + resctrl_arch_set_cdp_enabled(RDT_RESOURCE_L2, false); +out: return ret; } @@ -2497,13 +2513,13 @@ static int rdt_get_tree(struct fs_context *fc) } ret = rdt_enable_ctx(ctx); - if (ret < 0) - goto out_cdp; + if (ret) + goto out; ret = schemata_list_create(); if (ret) { schemata_list_destroy(); - goto out_mba; + goto out_ctx; } closid_init(); @@ -2562,10 +2578,9 @@ static int rdt_get_tree(struct fs_context *fc) kernfs_remove(kn_info); out_schemata_free: schemata_list_destroy(); -out_mba: +out_ctx: if (ctx->enable_mba_mbps) set_mba_sc(false); -out_cdp: cdp_disable_all(); out: rdt_last_cmd_clear();