From: Jinjie Ruan <ruanjinjie01@gmail.com>
To: babu.moger@amd.com, ben.horgan@arm.com, bp@alien8.de,
corbet@lwn.net, dave.hansen@linux.intel.com, Dave.Martin@arm.com,
fenghuay@nvidia.com, gshan@redhat.com, hpa@zytor.com,
james.morse@arm.com, jic23@kernel.org, mingo@redhat.com,
rdunlap@infradead.org, reinette.chatre@intel.com,
skhan@linuxfoundation.org, tan.shaopeng@fujitsu.com,
tglx@kernel.org, tony.luck@intel.com, zengheng4@huawei.com,
x86@kernel.org, linux-kernel@vger.kernel.org,
linux-doc@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Cc: ruanjinjie@huawei.com
Subject: [PATCH v5 4/7] fs/resctrl: Stop the limbo handler while resctrl is unmounted
Date: Tue, 10 Nov 2026 21:20:51 +0800 [thread overview]
Message-ID: <20261110132054.3702-5-ruanjinjie01@gmail.com> (raw)
In-Reply-To: <20261110132054.3702-1-ruanjinjie01@gmail.com>
From: Jinjie Ruan <ruanjinjie@huawei.com>
A group's RMID is not returned to the free list when the group is
removed. It stays in limbo until the cache lines tagged with it are
evicted, and the limbo handler reads its occupancy counter in the
meantime. The limbo handler keeps running after resctrl is unmounted,
while the MBM overflow handler stops once resctrl_mounted is cleared.
Reading the RMIDs in limbo while resctrl is unmounted is not safe on
every architecture. On MPAM the counter of an RMID is selected by the
PARTIDs of the CLOSID that owned it, and the CLOSID to PARTID mapping
depends on the CDP state. The unmount clears the CDP state, so the
handler that keeps running reads the RMIDs freed under CDP through the
PARTIDs of the cleared state.
Stop the limbo handler while resctrl is unmounted, as the overflow
handler does, and restart it after a mount on every domain that still
has RMIDs in limbo. The worker can stay queued across the unmount, so
cancel it before queuing it again. This keeps the limbo handler
lifetime the same on every architecture.
On x86 the RMIDs in limbo are no longer drained while resctrl is
unmounted. Nothing needs them until the mount that follows the
unmount, after which the handler frees them as before.
Fixes: 6789fb99282c ("arm_mpam: resctrl: Add CDP emulation")
Suggested-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
Cc: <stable@vger.kernel.org> # 7.1+
---
fs/resctrl/internal.h | 1 +
fs/resctrl/monitor.c | 43 +++++++++++++++++++++++++++++++++++++++++--
fs/resctrl/rdtgroup.c | 2 ++
3 files changed, 44 insertions(+), 2 deletions(-)
diff --git a/fs/resctrl/internal.h b/fs/resctrl/internal.h
index 1c85e06f09bf..c95fa6ce62e6 100644
--- a/fs/resctrl/internal.h
+++ b/fs/resctrl/internal.h
@@ -373,6 +373,7 @@ void closid_free(int closid);
int setup_rmid_lru_list(void);
void free_rmid_lru_list(void);
+void resctrl_limbo_resume(void);
int alloc_rmid(u32 closid);
diff --git a/fs/resctrl/monitor.c b/fs/resctrl/monitor.c
index ae9ddd380515..f56d0e32fd06 100644
--- a/fs/resctrl/monitor.c
+++ b/fs/resctrl/monitor.c
@@ -852,6 +852,13 @@ void cqm_handle_limbo(struct work_struct *work)
*/
mutex_lock(&rdtgroup_mutex);
+ /*
+ * If the filesystem has been unmounted this work no longer needs to
+ * run. resctrl_limbo_resume() restarts it on the next mount.
+ */
+ if (!resctrl_mounted)
+ goto out_unlock;
+
/*
* Ensure the worker is dedicated to a CPU as intended and not
* relocated by workqueue subsystem as part of CPU going offline.
@@ -1001,8 +1008,8 @@ int setup_rmid_lru_list(void)
/*
* Called on every mount, but the number of RMIDs cannot change
* after the first mount, so keep using the same set of rmid_ptrs[]
- * until resctrl_exit(). Note that the limbo handler continues to
- * access rmid_ptrs[] after resctrl is unmounted.
+ * until resctrl_exit(). Note that the RMIDs in limbo stay in limbo
+ * across an unmount and are checked again after the next mount.
*/
if (rmid_ptrs)
return 0;
@@ -1033,6 +1040,38 @@ int setup_rmid_lru_list(void)
return 0;
}
+/**
+ * resctrl_limbo_resume() - Restart the limbo handler after a mount.
+ *
+ * The limbo handler stops while resctrl is unmounted. Restart it on every
+ * domain that still has RMIDs in limbo.
+ */
+void resctrl_limbo_resume(void)
+{
+ struct rdt_l3_mon_domain *d;
+ struct rdt_resource *r;
+
+ lockdep_assert_cpus_held();
+ lockdep_assert_held(&rdtgroup_mutex);
+
+ if (!resctrl_is_mon_event_enabled(QOS_L3_OCCUP_EVENT_ID))
+ return;
+
+ r = resctrl_arch_get_resource(RDT_RESOURCE_L3);
+ list_for_each_entry_rcu(d, &r->mon_domains, hdr.list,
+ lockdep_is_cpus_held()) {
+ if (!has_busy_rmid(d))
+ continue;
+
+ /*
+ * The unmount may have left the worker queued. Cancel it so
+ * it is queued again on a CPU picked now.
+ */
+ cancel_delayed_work(&d->cqm_limbo);
+ cqm_setup_limbo_handler(d, 0, RESCTRL_PICK_ANY_CPU);
+ }
+}
+
void free_rmid_lru_list(void)
{
if (!resctrl_arch_mon_capable())
diff --git a/fs/resctrl/rdtgroup.c b/fs/resctrl/rdtgroup.c
index 3312637fb514..b702fe6dbbec 100644
--- a/fs/resctrl/rdtgroup.c
+++ b/fs/resctrl/rdtgroup.c
@@ -3267,6 +3267,8 @@ static int rdt_get_tree(struct fs_context *fc)
RESCTRL_PICK_ANY_CPU);
}
+ resctrl_limbo_resume();
+
/*
* Ensure root remains accessible after mutex is unlocked so that
* kernfs_kill_sb() can run safely if called by kernfs_get_tree()'s
--
2.43.0
next prev parent reply other threads:[~2026-11-10 13:21 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-10 13:20 [PATCH v5 0/7] fs/resctrl: Fix some resctl bugs related to mpam Jinjie Ruan
2026-11-10 13:20 ` [PATCH v5 1/7] fs/resctrl: Report a temporary RMID shortage per CLOSID Jinjie Ruan
2026-11-10 13:33 ` Jinjie Ruan
2026-11-10 13:20 ` [PATCH v5 2/7] fs/resctrl: Do not allocate a monitor context when releasing limbo RMIDs Jinjie Ruan
2026-11-10 13:20 ` [PATCH v5 3/7] fs/resctrl: Clear the CDP state after the cleanup Jinjie Ruan
2026-11-10 13:20 ` Jinjie Ruan [this message]
2026-11-10 13:20 ` [PATCH v5 5/7] fs/resctrl: Release the limbo RMIDs when the CDP state changes Jinjie Ruan
2026-11-10 13:20 ` [PATCH v5 6/7] fs/resctrl: Disallow monitor group move when the RMID index changes Jinjie Ruan
2026-11-10 13:20 ` [PATCH v5 7/7] fs/resctrl: Add info/moveable_mon_group Jinjie Ruan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261110132054.3702-5-ruanjinjie01@gmail.com \
--to=ruanjinjie01@gmail.com \
--cc=Dave.Martin@arm.com \
--cc=babu.moger@amd.com \
--cc=ben.horgan@arm.com \
--cc=bp@alien8.de \
--cc=corbet@lwn.net \
--cc=dave.hansen@linux.intel.com \
--cc=fenghuay@nvidia.com \
--cc=gshan@redhat.com \
--cc=hpa@zytor.com \
--cc=james.morse@arm.com \
--cc=jic23@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=rdunlap@infradead.org \
--cc=reinette.chatre@intel.com \
--cc=ruanjinjie@huawei.com \
--cc=skhan@linuxfoundation.org \
--cc=tan.shaopeng@fujitsu.com \
--cc=tglx@kernel.org \
--cc=tony.luck@intel.com \
--cc=x86@kernel.org \
--cc=zengheng4@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®