Message ID | 20230914172138.11977-3-james.morse@arm.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:172:b0:3f2:4152:657d with SMTP id h50csp511944vqi; Thu, 14 Sep 2023 10:34:29 -0700 (PDT) X-Google-Smtp-Source: AGHT+IE25qYOHc5UkcowrrUdVqMLPWzVmFQzU+VdHrKTlmEbvhqVA9e4zsIz8s6yb6MTfmFjB3KF X-Received: by 2002:a05:6a00:1a8a:b0:68e:2b17:a729 with SMTP id e10-20020a056a001a8a00b0068e2b17a729mr6757034pfv.24.1694712869610; Thu, 14 Sep 2023 10:34:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1694712869; cv=none; d=google.com; s=arc-20160816; b=sKL192J7vR85VTwLlxX3pBZdWyDFbQV7M5WxH9OFdEKzrucMLdkVCfkj3dsN8edhRT kaLiuH+QnQiOZEs9yFyXk6lh+INi6g+9aIz+UaDybmWk5VxDgt06ZsJb/dB/a5lW9TMN OssJpftiIW/oK38NrH8t62FdD3cp7pGABDq6m/l/rX0Ggj98aXopTov8CbCCQB58/TCF i4P0AFOZ4paOskZOtXkWgxoX7Bi2GVKJYHfhE9nl9IyN1HIrlvL/Uxr6+Ch5y3jd40p8 eTzNPHPAanii2X5iG/Ch6QiBB383Z2MD3t7JdbTA/G/wEE8muzaKHKitYEqDqUKI4XDV xbfA== 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=GmBu9z4ZK/2idhlp9g1TEFd5uJd5zE2XSvRAxzlkdXU=; fh=6Nl2MjDBXofbhMXyzAhf7L7loTtEBflFxRNey74qSFc=; b=lEv+OdfciEomDsd6foOglaEoS7XjWRpD6CeFrvm3vFJ4WK5WYQgvDo2fDj2KrRN4Al dMnvoY5lYEug2n08q+ELmtMWvl8sdtGr5nefnkwCBZMg52qX0aCJBrf3kG7UgeXO5/PP X739nWG++D7G1K52sk0x44dg+EinIHnNcqdnNZz6zbISx+RNUs/d6cWxsxI8tiIvuDk/ KVcYd+v6sj4S+VbzgxxLAGvbkgknhF5isGrUQEx6hyTdzZXMvjv2So5dZh/WwW1wLdo+ CAWf8EbWeOlf8gpKwoQBiQ/fncnzGyYZr+aB+JowDTLoQnsFHeBAkRGvVypkQratgWmm cFOQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.31 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 morse.vger.email (morse.vger.email. [23.128.96.31]) by mx.google.com with ESMTPS id eb8-20020a056a004c8800b0068fcccf5c87si1950904pfb.300.2023.09.14.10.34.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 14 Sep 2023 10:34:29 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.31 as permitted sender) client-ip=23.128.96.31; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.31 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 (depot.vger.email [IPv6:2620:137:e000::3:0]) by morse.vger.email (Postfix) with ESMTP id 43790806662A; Thu, 14 Sep 2023 10:22:14 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at morse.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239042AbjINRWK (ORCPT <rfc822;pwkd43@gmail.com> + 33 others); Thu, 14 Sep 2023 13:22:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46102 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238865AbjINRWG (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 14 Sep 2023 13:22:06 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 48FA31BFE for <linux-kernel@vger.kernel.org>; Thu, 14 Sep 2023 10:22:02 -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 3BFD312FC; Thu, 14 Sep 2023 10:22:39 -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 36FDD3F5A1; Thu, 14 Sep 2023 10:21:59 -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, xingxin.hx@openanolis.org, baolin.wang@linux.alibaba.com, Jamie Iles <quic_jiles@quicinc.com>, Xin Hao <xhao@linux.alibaba.com>, peternewman@google.com, dfustini@baylibre.com, amitsinght@marvell.com Subject: [PATCH v6 02/24] x86/resctrl: kfree() rmid_ptrs from rdtgroup_exit() Date: Thu, 14 Sep 2023 17:21:16 +0000 Message-Id: <20230914172138.11977-3-james.morse@arm.com> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20230914172138.11977-1-james.morse@arm.com> References: <20230914172138.11977-1-james.morse@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (morse.vger.email [0.0.0.0]); Thu, 14 Sep 2023 10:22:15 -0700 (PDT) X-Spam-Status: No, score=-0.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on morse.vger.email X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1777035241926628323 X-GMAIL-MSGID: 1777035241926628323 |
Series |
x86/resctrl: monitored closid+rmid together, separate arch/fs locking
|
|
Commit Message
James Morse
Sept. 14, 2023, 5:21 p.m. UTC
rmid_ptrs[] is allocated from dom_data_init() but never free()d.
While the exit text ends up in the linker script's DISCARD section,
the direction of travel is for resctrl to be/have loadable modules.
Add resctrl_exit_mon_l3_config() to cleanup any memory allocated
by rdt_get_mon_l3_config().
There is no reason to backport this to a stable kernel.
Signed-off-by: James Morse <james.morse@arm.com>
---
Changes since v5:
* This patch is new
---
arch/x86/kernel/cpu/resctrl/internal.h | 1 +
arch/x86/kernel/cpu/resctrl/monitor.c | 10 ++++++++++
arch/x86/kernel/cpu/resctrl/rdtgroup.c | 5 +++++
3 files changed, 16 insertions(+)
Comments
Hi James, On 9/14/2023 10:21 AM, James Morse wrote: ... > diff --git a/arch/x86/kernel/cpu/resctrl/rdtgroup.c b/arch/x86/kernel/cpu/resctrl/rdtgroup.c > index 725344048f85..a2158c266e41 100644 > --- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c > +++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c > @@ -3867,6 +3867,11 @@ int __init rdtgroup_init(void) > > void __exit rdtgroup_exit(void) > { > + struct rdt_resource *r = &rdt_resources_all[RDT_RESOURCE_L3].r_resctrl; > + > + if (r->mon_capable) > + resctrl_exit_mon_l3_config(r); > + > debugfs_remove_recursive(debugfs_resctrl); > unregister_filesystem(&rdt_fs_type); > sysfs_remove_mount_point(fs_kobj, "resctrl"); You did not respond to me when I requested that this be done differently [1]. Without a response letting me know the faults of my proposal or following the recommendation I conclude that my feedback was ignored. Reinette [1] https://lore.kernel.org/lkml/1ccd6be5-1dbd-c4a5-659f-ae20761dcce7@intel.com/
Hi James, On 9/14/23 12:21, James Morse wrote: > rmid_ptrs[] is allocated from dom_data_init() but never free()d. > > While the exit text ends up in the linker script's DISCARD section, > the direction of travel is for resctrl to be/have loadable modules. > > Add resctrl_exit_mon_l3_config() to cleanup any memory allocated > by rdt_get_mon_l3_config(). > > There is no reason to backport this to a stable kernel. > > Signed-off-by: James Morse <james.morse@arm.com> > --- > Changes since v5: > * This patch is new > --- > arch/x86/kernel/cpu/resctrl/internal.h | 1 + > arch/x86/kernel/cpu/resctrl/monitor.c | 10 ++++++++++ > arch/x86/kernel/cpu/resctrl/rdtgroup.c | 5 +++++ > 3 files changed, 16 insertions(+) > > diff --git a/arch/x86/kernel/cpu/resctrl/internal.h b/arch/x86/kernel/cpu/resctrl/internal.h > index 85ceaf9a31ac..57cf1e6a57bd 100644 > --- a/arch/x86/kernel/cpu/resctrl/internal.h > +++ b/arch/x86/kernel/cpu/resctrl/internal.h > @@ -537,6 +537,7 @@ void closid_free(int closid); > int alloc_rmid(void); > void free_rmid(u32 rmid); > int rdt_get_mon_l3_config(struct rdt_resource *r); > +void resctrl_exit_mon_l3_config(struct rdt_resource *r); > bool __init rdt_cpu_has(int flag); > void mon_event_count(void *info); > int rdtgroup_mondata_show(struct seq_file *m, void *arg); > diff --git a/arch/x86/kernel/cpu/resctrl/monitor.c b/arch/x86/kernel/cpu/resctrl/monitor.c > index ded1fc7cb7cb..cfb3f632a4b2 100644 > --- a/arch/x86/kernel/cpu/resctrl/monitor.c > +++ b/arch/x86/kernel/cpu/resctrl/monitor.c > @@ -741,6 +741,16 @@ static int dom_data_init(struct rdt_resource *r) > return 0; > } > > +void resctrl_exit_mon_l3_config(struct rdt_resource *r) > +{ > + mutex_lock(&rdtgroup_mutex); > + > + kfree(rmid_ptrs); > + rmid_ptrs = NULL; > + > + mutex_unlock(&rdtgroup_mutex); > +} What is the need for passing "rdt_resource *r" here? Is mutex_lock required? Thanks Babu
Hi Reinette, On 02/10/2023 18:00, Reinette Chatre wrote: > On 9/14/2023 10:21 AM, James Morse wrote: >> diff --git a/arch/x86/kernel/cpu/resctrl/rdtgroup.c b/arch/x86/kernel/cpu/resctrl/rdtgroup.c >> index 725344048f85..a2158c266e41 100644 >> --- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c >> +++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c >> @@ -3867,6 +3867,11 @@ int __init rdtgroup_init(void) >> >> void __exit rdtgroup_exit(void) >> { >> + struct rdt_resource *r = &rdt_resources_all[RDT_RESOURCE_L3].r_resctrl; >> + >> + if (r->mon_capable) >> + resctrl_exit_mon_l3_config(r); >> + >> debugfs_remove_recursive(debugfs_resctrl); >> unregister_filesystem(&rdt_fs_type); >> sysfs_remove_mount_point(fs_kobj, "resctrl"); > > You did not respond to me when I requested that this be done differently [1]. > Without a response letting me know the faults of my proposal or following the > recommendation I conclude that my feedback was ignored. Not so - I just trimmed the bits that didn't need a response. I can respond 'Yes' to each one if you prefer, but I find that adds more noise than signal. This is my attempt at 'doing the cleanup properly', which is what you said your preference was. (no machine on the planet can ever run this code, the __exit section is always discarded by the linker). Reading through again, I missed that you wanted this called from resctrl_exit(). (The naming suggests I did this originally, but it didn't work out). I don't think this works as the code in resctrl_exit() remains part of the arch code after the move, but allocating rmid_ptrs[] stays part of the fs code. resctrl_exit() in core.c gets renamed as resctrl_arch_exit(), and rdtgroup_exit() takes on the name resctrl_exit() as its part of the exposed interface. Thanks, James
Hi Babu, On 04/10/2023 19:00, Moger, Babu wrote: > On 9/14/23 12:21, James Morse wrote: >> rmid_ptrs[] is allocated from dom_data_init() but never free()d. >> >> While the exit text ends up in the linker script's DISCARD section, >> the direction of travel is for resctrl to be/have loadable modules. >> >> Add resctrl_exit_mon_l3_config() to cleanup any memory allocated >> by rdt_get_mon_l3_config(). >> >> There is no reason to backport this to a stable kernel. >> diff --git a/arch/x86/kernel/cpu/resctrl/internal.h b/arch/x86/kernel/cpu/resctrl/internal.h >> index 85ceaf9a31ac..57cf1e6a57bd 100644 >> --- a/arch/x86/kernel/cpu/resctrl/internal.h >> +++ b/arch/x86/kernel/cpu/resctrl/internal.h >> @@ -537,6 +537,7 @@ void closid_free(int closid); >> int alloc_rmid(void); >> void free_rmid(u32 rmid); >> int rdt_get_mon_l3_config(struct rdt_resource *r); >> +void resctrl_exit_mon_l3_config(struct rdt_resource *r); >> bool __init rdt_cpu_has(int flag); >> void mon_event_count(void *info); >> int rdtgroup_mondata_show(struct seq_file *m, void *arg); >> diff --git a/arch/x86/kernel/cpu/resctrl/monitor.c b/arch/x86/kernel/cpu/resctrl/monitor.c >> index ded1fc7cb7cb..cfb3f632a4b2 100644 >> --- a/arch/x86/kernel/cpu/resctrl/monitor.c >> +++ b/arch/x86/kernel/cpu/resctrl/monitor.c >> @@ -741,6 +741,16 @@ static int dom_data_init(struct rdt_resource *r) >> return 0; >> } >> >> +void resctrl_exit_mon_l3_config(struct rdt_resource *r) >> +{ >> + mutex_lock(&rdtgroup_mutex); >> + >> + kfree(rmid_ptrs); >> + rmid_ptrs = NULL; >> + >> + mutex_unlock(&rdtgroup_mutex); >> +} > What is the need for passing "rdt_resource *r" here? My vain belief that monitors should be supported on something other than L3, but I agree that isn't what resctrl does today. I'll remove it. > Is mutex_lock required? Reads and writes to rmid_ptrs[] are protected by that lock. This ensures no-one reads the value while its being free()d, and after this function releases the lock, anyone trying sees NULL. (This is all moot as its only caller is marked __exit, so gets discarded by the linker) Thanks, James
Hi James, On 10/5/2023 10:05 AM, James Morse wrote: > On 02/10/2023 18:00, Reinette Chatre wrote: >> On 9/14/2023 10:21 AM, James Morse wrote: >>> diff --git a/arch/x86/kernel/cpu/resctrl/rdtgroup.c b/arch/x86/kernel/cpu/resctrl/rdtgroup.c >>> index 725344048f85..a2158c266e41 100644 >>> --- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c >>> +++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c >>> @@ -3867,6 +3867,11 @@ int __init rdtgroup_init(void) >>> >>> void __exit rdtgroup_exit(void) >>> { >>> + struct rdt_resource *r = &rdt_resources_all[RDT_RESOURCE_L3].r_resctrl; >>> + >>> + if (r->mon_capable) >>> + resctrl_exit_mon_l3_config(r); >>> + >>> debugfs_remove_recursive(debugfs_resctrl); >>> unregister_filesystem(&rdt_fs_type); >>> sysfs_remove_mount_point(fs_kobj, "resctrl"); >> >> You did not respond to me when I requested that this be done differently [1]. >> Without a response letting me know the faults of my proposal or following the >> recommendation I conclude that my feedback was ignored. > > Not so - I just trimmed the bits that didn't need a response. I can respond 'Yes' to each > one if you prefer, but I find that adds more noise than signal. I do not expect a response to every review feedback but no response is assumed to mean that you agree with the feedback. > > This is my attempt at 'doing the cleanup properly', which is what you said your preference > was. (no machine on the planet can ever run this code, the __exit section is always > discarded by the linker). > > Reading through again, I missed that you wanted this called from resctrl_exit(). (The Right. And not responding to that created expectation that you agreed with the request. > naming suggests I did this originally, but it didn't work out). > I don't think this works as the code in resctrl_exit() remains part of the arch code after > the move, but allocating rmid_ptrs[] stays part of the fs code. > > resctrl_exit() in core.c gets renamed as resctrl_arch_exit(), and rdtgroup_exit() takes on > the name resctrl_exit() as its part of the exposed interface. I expect memory allocation/free to be symmetrical. Doing otherwise complicates the code. Having this memory freed in rdtgroup_exit() only seems appropriate if it is allocated from rdtgroup_init(). Neither rmid_ptrs[] nor closid_num_dirty_rmid are allocated in rdtgroup_init() so freeing it in rdtgroup_exit() is not appropriate. If you are planning to move resctrl_exit() to be arch code then I expect resctrl_late_init() to be split with the rmid_ptrs[]/closid_num_dirty_rmid allocation moving to fs code. Freeing that memory can follow at that time. Reinette
Hi Reinette, On 05/10/2023 19:04, Reinette Chatre wrote: > On 10/5/2023 10:05 AM, James Morse wrote: >> On 02/10/2023 18:00, Reinette Chatre wrote: >>> On 9/14/2023 10:21 AM, James Morse wrote: >>>> diff --git a/arch/x86/kernel/cpu/resctrl/rdtgroup.c b/arch/x86/kernel/cpu/resctrl/rdtgroup.c >>>> index 725344048f85..a2158c266e41 100644 >>>> --- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c >>>> +++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c >>>> @@ -3867,6 +3867,11 @@ int __init rdtgroup_init(void) >>>> >>>> void __exit rdtgroup_exit(void) >>>> { >>>> + struct rdt_resource *r = &rdt_resources_all[RDT_RESOURCE_L3].r_resctrl; >>>> + >>>> + if (r->mon_capable) >>>> + resctrl_exit_mon_l3_config(r); >>>> + >>>> debugfs_remove_recursive(debugfs_resctrl); >>>> unregister_filesystem(&rdt_fs_type); >>>> sysfs_remove_mount_point(fs_kobj, "resctrl"); >>> >>> You did not respond to me when I requested that this be done differently [1]. >>> Without a response letting me know the faults of my proposal or following the >>> recommendation I conclude that my feedback was ignored. >> >> Not so - I just trimmed the bits that didn't need a response. I can respond 'Yes' to each >> one if you prefer, but I find that adds more noise than signal. > > I do not expect a response to every review feedback but no response > is assumed to mean that you agree with the feedback. > >> >> This is my attempt at 'doing the cleanup properly', which is what you said your preference >> was. (no machine on the planet can ever run this code, the __exit section is always >> discarded by the linker). >> >> Reading through again, I missed that you wanted this called from resctrl_exit(). (The > > Right. And not responding to that created expectation that you agreed with the > request. > >> naming suggests I did this originally, but it didn't work out). >> I don't think this works as the code in resctrl_exit() remains part of the arch code after >> the move, but allocating rmid_ptrs[] stays part of the fs code. >> >> resctrl_exit() in core.c gets renamed as resctrl_arch_exit(), and rdtgroup_exit() takes on >> the name resctrl_exit() as its part of the exposed interface. > > I expect memory allocation/free to be symmetrical. Doing otherwise > complicates the code. Having this memory freed in rdtgroup_exit() only > seems appropriate if it is allocated from rdtgroup_init(). > Neither rmid_ptrs[] nor closid_num_dirty_rmid are allocated in > rdtgroup_init() so freeing it in rdtgroup_exit() is not appropriate. It probably makes more sense when you see how things get split up. I was trying to reduce the churn of adding something in one place, then moving it later. For now I've added all the functions to make this thing symmetric. James > If you are planning to move resctrl_exit() to be arch code then I expect > resctrl_late_init() to be split with the rmid_ptrs[]/closid_num_dirty_rmid > allocation moving to fs code. Freeing that memory can follow at that time.
diff --git a/arch/x86/kernel/cpu/resctrl/internal.h b/arch/x86/kernel/cpu/resctrl/internal.h index 85ceaf9a31ac..57cf1e6a57bd 100644 --- a/arch/x86/kernel/cpu/resctrl/internal.h +++ b/arch/x86/kernel/cpu/resctrl/internal.h @@ -537,6 +537,7 @@ void closid_free(int closid); int alloc_rmid(void); void free_rmid(u32 rmid); int rdt_get_mon_l3_config(struct rdt_resource *r); +void resctrl_exit_mon_l3_config(struct rdt_resource *r); bool __init rdt_cpu_has(int flag); void mon_event_count(void *info); int rdtgroup_mondata_show(struct seq_file *m, void *arg); diff --git a/arch/x86/kernel/cpu/resctrl/monitor.c b/arch/x86/kernel/cpu/resctrl/monitor.c index ded1fc7cb7cb..cfb3f632a4b2 100644 --- a/arch/x86/kernel/cpu/resctrl/monitor.c +++ b/arch/x86/kernel/cpu/resctrl/monitor.c @@ -741,6 +741,16 @@ static int dom_data_init(struct rdt_resource *r) return 0; } +void resctrl_exit_mon_l3_config(struct rdt_resource *r) +{ + mutex_lock(&rdtgroup_mutex); + + kfree(rmid_ptrs); + rmid_ptrs = NULL; + + mutex_unlock(&rdtgroup_mutex); +} + static struct mon_evt llc_occupancy_event = { .name = "llc_occupancy", .evtid = QOS_L3_OCCUP_EVENT_ID, diff --git a/arch/x86/kernel/cpu/resctrl/rdtgroup.c b/arch/x86/kernel/cpu/resctrl/rdtgroup.c index 725344048f85..a2158c266e41 100644 --- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c +++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c @@ -3867,6 +3867,11 @@ int __init rdtgroup_init(void) void __exit rdtgroup_exit(void) { + struct rdt_resource *r = &rdt_resources_all[RDT_RESOURCE_L3].r_resctrl; + + if (r->mon_capable) + resctrl_exit_mon_l3_config(r); + debugfs_remove_recursive(debugfs_resctrl); unregister_filesystem(&rdt_fs_type); sysfs_remove_mount_point(fs_kobj, "resctrl");