From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from canpmsgout04.his.huawei.com (canpmsgout04.his.huawei.com [113.46.200.219]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 24AD73AB29F for ; Mon, 13 Apr 2026 08:54:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.219 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776070462; cv=none; b=hpOKVTn0+35Yf6GWPq2Wzca/h5/0AUKoJYKIHyL28uVNnjxj4G16fTnLtoiMBBy0Ntj/km80wY/GhRMVlkH9qDeV2zi/OXn2IdpPa1dRx/J6nRj2tpBESIjdiLmPgDgzPrl6YfZGFkBzhVjeQU8DYBbQY3Fi/ogHRX9U9fmu8L8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776070462; c=relaxed/simple; bh=ALgp9yvWFp+sfN+yE12xdxympmH8U5QnCYiwDK1fHIg=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=okRMYYycuLlZgdCaryJkg0FUDmv4xXRYtHfa3tS75pZ/IsmS2E0krczJ1gipvRFCObZW0xs3u9sZl6DXAjijRp7wWRHMXs3dIgjUySjQyFEzuqPKhmgwgcBUVoA4PwXvevrEjaPi1mZjsflS3WoPZn+3sHuuW3Kmv58oNba1Z9k= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=h-partners.com; dkim=pass (1024-bit key) header.d=h-partners.com header.i=@h-partners.com header.b=G2FLyrGr; arc=none smtp.client-ip=113.46.200.219 Authentication-Results: smtp.subspace.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=h-partners.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=h-partners.com header.i=@h-partners.com header.b="G2FLyrGr" dkim-signature: v=1; a=rsa-sha256; d=h-partners.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=op08HCqJ4u4oJC1zLRF5Zh2ZqxSUZczSTa3QNhH8QVA=; b=G2FLyrGrPKf+8n2pI2yjcDLwbWNb6INdPxOhRr6yWLH71z2EQondVn7PF1bd6al4gjqmGE/E4 Cef/wBNiNoPrycoMuwQn9j8JES9tGwR1GzorG8WFLDb9KC0wtLKW3AYw0BLg3EhsgCadNf9AJpp 2SyrGg5C9yO+/ySKohZ2ePY= Received: from mail.maildlp.com (unknown [172.19.162.223]) by canpmsgout04.his.huawei.com (SkyGuard) with ESMTPS id 4fvLdm54zxz1prNH; Mon, 13 Apr 2026 16:47:56 +0800 (CST) Received: from kwepemf100008.china.huawei.com (unknown [7.202.181.222]) by mail.maildlp.com (Postfix) with ESMTPS id 97BDD40561; Mon, 13 Apr 2026 16:54:16 +0800 (CST) Received: from huawei.com (10.50.87.109) by kwepemf100008.china.huawei.com (7.202.181.222) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.36; Mon, 13 Apr 2026 16:54:15 +0800 From: Zeng Heng To: , , , , , , , , , , , , , , , CC: , , , Subject: [PATCH v8 next 01/10] fs/resctrl: Fix MPAM Partid parsing errors by preserving CDP state during umount Date: Mon, 13 Apr 2026 16:53:56 +0800 Message-ID: <20260413085405.1166412-2-zengheng4@huawei.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20260413085405.1166412-1-zengheng4@huawei.com> References: <20260413085405.1166412-1-zengheng4@huawei.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: kwepems100001.china.huawei.com (7.221.188.238) To kwepemf100008.china.huawei.com (7.202.181.222) 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 makes 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 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 fix addresses the immediate correctness issue with minimal churn. Signed-off-by: Zeng Heng --- 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 5dfdaa6f9d8f..69966589713f 100644 --- a/fs/resctrl/rdtgroup.c +++ b/fs/resctrl/rdtgroup.c @@ -3169,6 +3169,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; @@ -3176,13 +3195,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()) -- 2.25.1