From: Ben Horgan <ben.horgan@arm.com>
To: Zeng Heng <zengheng4@huawei.com>,
james.morse@arm.com, Dave.Martin@arm.com,
reinette.chatre@intel.com, fenghuay@nvidia.com
Cc: dave.hansen@linux.intel.com, tglx@kernel.org, mingo@redhat.com,
hpa@zytor.com, bp@alien8.de, tony.luck@intel.com,
babu.moger@amd.com, x86@kernel.org, linux-kernel@vger.kernel.org,
wangkefeng.wang@huawei.com
Subject: Re: [PATCH v3 1/9] fs/resctrl: Fix MPAM Partid parsing errors by preserving CDP state during umount
Date: Fri, 20 Mar 2026 17:07:09 +0000 [thread overview]
Message-ID: <effc0fab-daee-45b1-990d-32a0eabdf8a6@arm.com> (raw)
In-Reply-To: <20260317132141.1272506-2-zengheng4@huawei.com>
Hi Zeng,
On 3/17/26 13:21, Zeng Heng wrote:
> This patch fixes a pre-existing issue in the resctrl filesystem teardown
> sequence where premature clearing of cdp_enabled could lead to MPAM Partid
> parsing errors.
>
> The closid to partid conversion logic inherently depends on the global
> cdp_enabled state. However, rdt_disable_ctx() clears this flag early in
> the umount path, while free_rmid() operations will reference after that.
> This creates a window where partid parsing operates with inconsistent CDP
> state, potentially make monitor reads with wrong partid mapping.
>
> Additionally, rmid_entry remaining in limbo between mount sessions may
> trigger potential partid out-of-range errors, leading to MPAM fault
> interrupts and subsequent MPAM disablement.
>
> Reorder rdt_kill_sb() to delay rdt_disable_ctx() until after
> rmdir_all_sub() and resctrl_fs_teardown() complete. This ensures
> all rmid-related operations finish with correct CDP state.
>
> Introduce rdt_flush_limbo() to flush and cancel limbo work before the
> filesystem teardown completes. An alternative approach would be to cancel
The code looks correct but it does introduce a subtle change of behaviour which
may or may not be acceptable. A busy rmid may now be allocated after remount.
Clean rmids were never guaranteed, e.g. when a domain goes offline, but this
weakens the guarantee.
> limbo work on umount and restart it on remount with remaked bitmap.
> However, this would require substantial changes in the resctrl layer to
> handle CDP state transitions across mount sessions, which is beyond the
> scope of the reqpartid feature work this patchset focuses on. The current
Another option to consider is whether limbo could be replaced by checking whether
an rmid is busy at allocation.
Do your changes here to resctrl_arch_rmid_idx_encode() have an impact on how
limbo works?
Thanks,
Ben
> fix addresses the immediate correctness issue with minimal churn.
>
> Signed-off-by: Zeng Heng <zengheng4@huawei.com>
> ---
> fs/resctrl/rdtgroup.c | 24 ++++++++++++++++++++++--
> 1 file changed, 22 insertions(+), 2 deletions(-)
>
> diff --git a/fs/resctrl/rdtgroup.c b/fs/resctrl/rdtgroup.c
> index 5da305bd36c9..bc0735eef92a 100644
> --- a/fs/resctrl/rdtgroup.c
> +++ b/fs/resctrl/rdtgroup.c
> @@ -3165,6 +3165,25 @@ static void resctrl_fs_teardown(void)
> rdtgroup_destroy_root();
> }
>
> +static void rdt_flush_limbo(void)
> +{
> + struct rdt_resource *r = resctrl_arch_get_resource(RDT_RESOURCE_L3);
> + struct rdt_l3_mon_domain *d;
> +
> + if (!IS_ENABLED(CONFIG_RESCTRL_RMID_DEPENDS_ON_CLOSID))
> + return;
> +
> + if (!resctrl_is_mon_event_enabled(QOS_L3_OCCUP_EVENT_ID))
> + return;
> +
> + list_for_each_entry(d, &r->mon_domains, hdr.list) {
> + if (has_busy_rmid(d)) {
> + __check_limbo(d, true);
> + cancel_delayed_work(&d->cqm_limbo);
> + }
> + }
> +}
> +
> static void rdt_kill_sb(struct super_block *sb)
> {
> struct rdt_resource *r;
> @@ -3172,13 +3191,14 @@ static void rdt_kill_sb(struct super_block *sb)
> cpus_read_lock();
> mutex_lock(&rdtgroup_mutex);
>
> - rdt_disable_ctx();
> -
> /* Put everything back to default values. */
> for_each_alloc_capable_rdt_resource(r)
> resctrl_arch_reset_all_ctrls(r);
>
> resctrl_fs_teardown();
> + rdt_flush_limbo();
> + rdt_disable_ctx();
> +
> if (resctrl_arch_alloc_capable())
> resctrl_arch_disable_alloc();
> if (resctrl_arch_mon_capable())
next prev parent reply other threads:[~2026-03-20 17:07 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-17 13:21 [PATCH v3 0/9] arm_mpam: Introduce Narrow-PARTID feature Zeng Heng
2026-03-17 13:21 ` [PATCH v3 1/9] fs/resctrl: Fix MPAM Partid parsing errors by preserving CDP state during umount Zeng Heng
2026-03-20 17:07 ` Ben Horgan [this message]
2026-03-21 4:11 ` Zeng Heng
2026-03-21 6:39 ` Zeng Heng
2026-03-17 13:21 ` [PATCH v3 2/9] arm_mpam: Add intPARTID and reqPARTID support for narrow PARTID feature Zeng Heng
2026-03-17 13:21 ` [PATCH v3 3/9] arm_mpam: Disable Narrow-PARTID when MBA lacks support Zeng Heng
2026-04-10 1:07 ` Shaopeng Tan (Fujitsu)
2026-04-11 6:50 ` Zeng Heng
2026-04-13 9:12 ` Zeng Heng
2026-03-17 13:21 ` [PATCH v3 4/9] arm_mpam: Refactor rmid to reqPARTID/PMG mapping Zeng Heng
2026-03-17 13:21 ` [PATCH v3 5/9] arm_mpam: Propagate control group config to sub-monitoring groups Zeng Heng
2026-03-17 13:21 ` [PATCH v3 6/9] fs/resctrl: Add rmid_entry state helpers Zeng Heng
2026-03-17 13:21 ` [PATCH v3 7/9] arm_mpam: Implement dynamic reqPARTID allocation for monitoring groups Zeng Heng
2026-03-17 13:21 ` [PATCH v3 8/9] fs/resctrl: Wire up rmid expansion and reclaim functions Zeng Heng
2026-03-17 13:21 ` [PATCH v3 9/9] arm64/mpam: Add mpam_sync_config() for dynamic rmid expansion Zeng Heng
2026-03-20 16:14 ` [PATCH v3 0/9] arm_mpam: Introduce Narrow-PARTID feature Ben Horgan
2026-03-21 7:18 ` Zeng Heng
2026-04-10 0:13 ` Shaopeng Tan (Fujitsu)
2026-04-11 6:32 ` Zeng Heng
2026-04-16 6:11 ` Shaopeng Tan (Fujitsu)
2026-04-20 8:19 ` Zeng Heng
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=effc0fab-daee-45b1-990d-32a0eabdf8a6@arm.com \
--to=ben.horgan@arm.com \
--cc=Dave.Martin@arm.com \
--cc=babu.moger@amd.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=fenghuay@nvidia.com \
--cc=hpa@zytor.com \
--cc=james.morse@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=reinette.chatre@intel.com \
--cc=tglx@kernel.org \
--cc=tony.luck@intel.com \
--cc=wangkefeng.wang@huawei.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®