Message ID | 20221021131204.5581-4-james.morse@arm.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4242:0:0:0:0:0 with SMTP id s2csp690614wrr; Fri, 21 Oct 2022 06:13:35 -0700 (PDT) X-Google-Smtp-Source: AMsMyM4dqCwBHWKItDJYGZPTYXme5qF1kK55Wa+c3ObAh+mRvWzSt7sLCNuDmC+m8o6nFFNsqqRm X-Received: by 2002:a17:903:1250:b0:185:40c6:3c2c with SMTP id u16-20020a170903125000b0018540c63c2cmr19497759plh.64.1666358015053; Fri, 21 Oct 2022 06:13:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666358015; cv=none; d=google.com; s=arc-20160816; b=n/SPj/QfGun4aaKK3LNVlAXclBxVJ5rc5i5nk9/QYuoL7uGw8JdNClW6AOl6FNBcTN Xw2+D5ls4eIff4tiZJqHQy5Q6OhnBFTd3KCqUsDLXECUoJwgkgMlOWprP2Mz7Bjx1CaT r0J7Z1m9cwv6L/ERCIoTMQjoZj0LhLjBeOatLpmMyRo46oIDCD9Wn4Rmi2n1qI72Lh51 zhPya7gCkgIUecRRQTHIFCMULtfmn9j2Qgt837oaIONMa/fqasX5rEfrM4AHVrO21rDK lQHp9Ja6V1oSLz2+utNybR+nh+hq+4kEcK1aD2jOdJgjJj85t16OaNjGlVLIJey7niE9 yAnA== 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 :references:in-reply-to:message-id:date:subject:cc:to:from; bh=EILKmT0Eh383MOLQwvVXC0UXgAgyas8vUmN9sOpBfiQ=; b=ZCRGkVND6IlxWdHXQ9g8Qj3rj3IgbRutkKWgJC9wEpJAk/D08n2wwxyu00UpY+GMpm jWAfEcGan2LiA/ajg/j7CaVtYFLqwNJYNpKU6/b419ZRiXW1BArWwMX1LWeVC7xWQXbY W3yBGFr0kpvxV5GJAd5pKhEl3OnZ8oGaGxoJJ9pRxpizW2n5PTIYzSAwB8qB1TXQzdHQ wFOpk7/c0eUGqW3phb4CpGg1b0G1jKaRMFEctYjRx70/qOu04LhMK+/hwswLA3dLT0BQ /f4ItAenH5zOliINOAL33eAcZIWgjSyJ0+kK2iN8Bc4ja7kDuttofL/O1h5M5NSKEpri 4i4A== ARC-Authentication-Results: i=1; mx.google.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=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id d10-20020a056a00198a00b005633c373dcbsi25810619pfl.147.2022.10.21.06.13.21; Fri, 21 Oct 2022 06:13:35 -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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230232AbiJUNND (ORCPT <rfc822;pwkd43@gmail.com> + 99 others); Fri, 21 Oct 2022 09:13:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35884 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230300AbiJUNMn (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 21 Oct 2022 09:12:43 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 38FB3263F14 for <linux-kernel@vger.kernel.org>; Fri, 21 Oct 2022 06:12:39 -0700 (PDT) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 6958D1480; Fri, 21 Oct 2022 06:12:44 -0700 (PDT) Received: from merodach.members.linode.com (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id CCA373F792; Fri, 21 Oct 2022 06:12:33 -0700 (PDT) From: James Morse <james.morse@arm.com> To: x86@kernel.org, linux-kernel@vger.kernel.org Cc: Fenghua Yu <fenghua.yu@intel.com>, Reinette Chatre <reinette.chatre@intel.com>, Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, H Peter Anvin <hpa@zytor.com>, Babu Moger <Babu.Moger@amd.com>, James Morse <james.morse@arm.com>, shameerali.kolothum.thodi@huawei.com, D Scott Phillips OS <scott@os.amperecomputing.com>, carl@os.amperecomputing.com, lcherian@marvell.com, bobo.shaobowang@huawei.com, tan.shaopeng@fujitsu.com, Jamie Iles <quic_jiles@quicinc.com>, Xin Hao <xhao@linux.alibaba.com>, xingxin.hx@openanolis.org, baolin.wang@linux.alibaba.com, peternewman@google.com Subject: [PATCH 03/18] x86/resctrl: Create helper for RMID allocation and mondata dir creation Date: Fri, 21 Oct 2022 13:11:49 +0000 Message-Id: <20221021131204.5581-4-james.morse@arm.com> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20221021131204.5581-1-james.morse@arm.com> References: <20221021131204.5581-1-james.morse@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW, SPF_HELO_NONE,SPF_NONE 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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1747303022329122929?= X-GMAIL-MSGID: =?utf-8?q?1747303022329122929?= |
Series |
x86/resctrl: monitored closid+rmid together, separate arch/fs locking
|
|
Commit Message
James Morse
Oct. 21, 2022, 1:11 p.m. UTC
RMID are allocated for each monitor or control group directory, because
each of these needs its own RMID. For control groups,
rdtgroup_mkdir_ctrl_mon() later goes on to allocate the CLOSID.
MPAM's equivalent of RMID are not an independent number, so can't be
allocated until the CLOSID is known. An RMID allocation for one CLOSID
may fail, whereas another may succeed depending on how many monitor
groups a control group has.
The RMID allocation needs to move to be after the CLOSID has been
allocated.
To make a subsequent change that does this easier to read, move the RMID
allocation and mondata dir creation to a helper.
Signed-off-by: James Morse <james.morse@arm.com>
---
arch/x86/kernel/cpu/resctrl/rdtgroup.c | 42 +++++++++++++++++---------
1 file changed, 27 insertions(+), 15 deletions(-)
Comments
Hi, James, > James Morse <james.morse@arm.com> writes: > > RMID are allocated for each monitor or control group directory, because each > of these needs its own RMID. For control groups, > rdtgroup_mkdir_ctrl_mon() later goes on to allocate the CLOSID. > > MPAM's equivalent of RMID are not an independent number, so can't be > allocated until the CLOSID is known. An RMID allocation for one CLOSID may fail, > whereas another may succeed depending on how many monitor groups a > control group has. > > The RMID allocation needs to move to be after the CLOSID has been allocated. > > To make a subsequent change that does this easier to read, move the RMID > allocation and mondata dir creation to a helper. > > Signed-off-by: James Morse <james.morse@arm.com> > --- > arch/x86/kernel/cpu/resctrl/rdtgroup.c | 42 +++++++++++++++++--------- > 1 file changed, 27 insertions(+), 15 deletions(-) > > diff --git a/arch/x86/kernel/cpu/resctrl/rdtgroup.c > b/arch/x86/kernel/cpu/resctrl/rdtgroup.c > index 9ce4746778f4..841294ad6263 100644 > --- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c > +++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c > @@ -2868,6 +2868,30 @@ static int rdtgroup_init_alloc(struct rdtgroup *rdtgrp) > return 0; > } > > +static int mkdir_rdt_prepare_rmid_alloc(struct rdtgroup *rdtgrp) { > + int ret; > + > + if (!rdt_mon_capable) > + return 0; > + > + ret = alloc_rmid(); > + if (ret < 0) { > + rdt_last_cmd_puts("Out of RMIDs\n"); > + return ret; > + } > + rdtgrp->mon.rmid = ret; > + > + ret = mkdir_mondata_all(rdtgrp->kn, rdtgrp, &rdtgrp- > >mon.mon_data_kn); > + if (ret) { > + rdt_last_cmd_puts("kernfs subdir error\n"); > + free_rmid(rdtgrp->closid, rdtgrp->mon.rmid); > + return ret; > + } > + > + return 0; > +} > + > static int mkdir_rdt_prepare(struct kernfs_node *parent_kn, > const char *name, umode_t mode, > enum rdt_group_type rtype, struct rdtgroup **r) > @@ -2933,20 +2957,10 @@ static int mkdir_rdt_prepare(struct kernfs_node > *parent_kn, > goto out_destroy; > } > > - if (rdt_mon_capable) { > - ret = alloc_rmid(); > - if (ret < 0) { > - rdt_last_cmd_puts("Out of RMIDs\n"); > - goto out_destroy; > - } > - rdtgrp->mon.rmid = ret; > + ret = mkdir_rdt_prepare_rmid_alloc(rdtgrp); > + if (ret) > + goto out_destroy; > > - ret = mkdir_mondata_all(kn, rdtgrp, &rdtgrp- > >mon.mon_data_kn); > - if (ret) { > - rdt_last_cmd_puts("kernfs subdir error\n"); > - goto out_idfree; > - } > - } > kernfs_activate(kn); > > /* > @@ -2954,8 +2968,6 @@ static int mkdir_rdt_prepare(struct kernfs_node > *parent_kn, > */ > return 0; > > -out_idfree: > - free_rmid(rdtgrp->closid, rdtgrp->mon.rmid); > out_destroy: > kernfs_put(rdtgrp->kn); > kernfs_remove(rdtgrp->kn); Why not free allocated rmid? Rmid leak without freed. Thanks. -Fenghua
Hi Fenghua, On 06/01/2023 03:23, Yu, Fenghua wrote: >> James Morse <james.morse@arm.com> writes: >> >> RMID are allocated for each monitor or control group directory, because each >> of these needs its own RMID. For control groups, >> rdtgroup_mkdir_ctrl_mon() later goes on to allocate the CLOSID. >> >> MPAM's equivalent of RMID are not an independent number, so can't be >> allocated until the CLOSID is known. An RMID allocation for one CLOSID may fail, >> whereas another may succeed depending on how many monitor groups a >> control group has. >> >> The RMID allocation needs to move to be after the CLOSID has been allocated. >> >> To make a subsequent change that does this easier to read, move the RMID >> allocation and mondata dir creation to a helper. >> diff --git a/arch/x86/kernel/cpu/resctrl/rdtgroup.c >> b/arch/x86/kernel/cpu/resctrl/rdtgroup.c >> index 9ce4746778f4..841294ad6263 100644 >> --- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c >> +++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c >> @@ -2868,6 +2868,30 @@ static int rdtgroup_init_alloc(struct rdtgroup *rdtgrp) >> return 0; >> } >> >> +static int mkdir_rdt_prepare_rmid_alloc(struct rdtgroup *rdtgrp) { >> + int ret; >> + >> + if (!rdt_mon_capable) >> + return 0; >> + >> + ret = alloc_rmid(); >> + if (ret < 0) { >> + rdt_last_cmd_puts("Out of RMIDs\n"); >> + return ret; >> + } >> + rdtgrp->mon.rmid = ret; >> + >> + ret = mkdir_mondata_all(rdtgrp->kn, rdtgrp, &rdtgrp- >>> mon.mon_data_kn); >> + if (ret) { >> + rdt_last_cmd_puts("kernfs subdir error\n"); >> + free_rmid(rdtgrp->closid, rdtgrp->mon.rmid); ^^^^^^^^^ >> + return ret; >> + } >> + >> + return 0; >> +} >> + >> static int mkdir_rdt_prepare(struct kernfs_node *parent_kn, >> const char *name, umode_t mode, >> enum rdt_group_type rtype, struct rdtgroup **r) >> @@ -2933,20 +2957,10 @@ static int mkdir_rdt_prepare(struct kernfs_node >> *parent_kn, >> goto out_destroy; >> } >> >> - if (rdt_mon_capable) { >> - ret = alloc_rmid(); >> - if (ret < 0) { >> - rdt_last_cmd_puts("Out of RMIDs\n"); >> - goto out_destroy; >> - } >> - rdtgrp->mon.rmid = ret; >> + ret = mkdir_rdt_prepare_rmid_alloc(rdtgrp); >> + if (ret) >> + goto out_destroy; >> >> - ret = mkdir_mondata_all(kn, rdtgrp, &rdtgrp- >>> mon.mon_data_kn); >> - if (ret) { >> - rdt_last_cmd_puts("kernfs subdir error\n"); >> - goto out_idfree; >> - } >> - } >> kernfs_activate(kn); >> >> /* >> @@ -2954,8 +2968,6 @@ static int mkdir_rdt_prepare(struct kernfs_node >> *parent_kn, >> */ >> return 0; >> >> -out_idfree: >> - free_rmid(rdtgrp->closid, rdtgrp->mon.rmid); >> out_destroy: >> kernfs_put(rdtgrp->kn); >> kernfs_remove(rdtgrp->kn); > Why not free allocated rmid? Rmid leak without freed. It's just moved into the helper. This free_rmid() is here because this function used to allocate the rmid and the mondata as separate steps. Now a helper does that in one go - and cleans up after itself. If mkdir_rdt_prepare_rmid_alloc() fails, it didn't allocate an rmid .. if it secretly did, it free()s it itself, see the ^-lighted code above. Thanks, James
diff --git a/arch/x86/kernel/cpu/resctrl/rdtgroup.c b/arch/x86/kernel/cpu/resctrl/rdtgroup.c index 9ce4746778f4..841294ad6263 100644 --- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c +++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c @@ -2868,6 +2868,30 @@ static int rdtgroup_init_alloc(struct rdtgroup *rdtgrp) return 0; } +static int mkdir_rdt_prepare_rmid_alloc(struct rdtgroup *rdtgrp) +{ + int ret; + + if (!rdt_mon_capable) + return 0; + + ret = alloc_rmid(); + if (ret < 0) { + rdt_last_cmd_puts("Out of RMIDs\n"); + return ret; + } + rdtgrp->mon.rmid = ret; + + ret = mkdir_mondata_all(rdtgrp->kn, rdtgrp, &rdtgrp->mon.mon_data_kn); + if (ret) { + rdt_last_cmd_puts("kernfs subdir error\n"); + free_rmid(rdtgrp->closid, rdtgrp->mon.rmid); + return ret; + } + + return 0; +} + static int mkdir_rdt_prepare(struct kernfs_node *parent_kn, const char *name, umode_t mode, enum rdt_group_type rtype, struct rdtgroup **r) @@ -2933,20 +2957,10 @@ static int mkdir_rdt_prepare(struct kernfs_node *parent_kn, goto out_destroy; } - if (rdt_mon_capable) { - ret = alloc_rmid(); - if (ret < 0) { - rdt_last_cmd_puts("Out of RMIDs\n"); - goto out_destroy; - } - rdtgrp->mon.rmid = ret; + ret = mkdir_rdt_prepare_rmid_alloc(rdtgrp); + if (ret) + goto out_destroy; - ret = mkdir_mondata_all(kn, rdtgrp, &rdtgrp->mon.mon_data_kn); - if (ret) { - rdt_last_cmd_puts("kernfs subdir error\n"); - goto out_idfree; - } - } kernfs_activate(kn); /* @@ -2954,8 +2968,6 @@ static int mkdir_rdt_prepare(struct kernfs_node *parent_kn, */ return 0; -out_idfree: - free_rmid(rdtgrp->closid, rdtgrp->mon.rmid); out_destroy: kernfs_put(rdtgrp->kn); kernfs_remove(rdtgrp->kn);