From nobody Thu Apr 2 20:28:25 2026 Received: from canpmsgout08.his.huawei.com (canpmsgout08.his.huawei.com [113.46.200.223]) (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 DA4592D8760 for ; Fri, 13 Feb 2026 07:51:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.223 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770969067; cv=none; b=b45eWPEqgPgQs2WpCIIXBQ2gxNg9N/Zs/DzkuahCwxgLc3xOc3UKdieh4ZWwqBuhJiyuDl3gE3H36G6sbx9mRRvV4WkrKz6yWocmsroz6pNQqI8Af/yXgObK86BQgIre8bfuBZKyyaFKQfm1wjXbaCVlKkDpYQDn02gPdNOSDPU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770969067; c=relaxed/simple; bh=rThyWygQhAmAkzRs180hW83NdW43v6XHnox5vOAm5RM=; h=From:To:CC:Subject:Date:Message-ID:MIME-Version:Content-Type; b=D1899gbzN/m+Udaf8+DKfR75LlUmYyCBXiVlDYpO/tjuDZrZy4DEWRl6TvcYlF1y6Vx1OQcjx2iUe9kCubh9jePZ+30VqPu2ncO/6oAJqmQqhkGOpOTySKnkTs5X1BzDs4RpfDggg9QNVK2WfXo8/7C76A5ncPSxIkupwfBAJzI= 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=G1mxN2b2; arc=none smtp.client-ip=113.46.200.223 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="G1mxN2b2" dkim-signature: v=1; a=rsa-sha256; d=h-partners.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=Xqw7qAtr+X2RiZVC2ezuGo28x3scBljk9HNDpQ4Cu3U=; b=G1mxN2b2/wuf4Wq3eRMqa9aJja9rPgtd1QkbNscnkVOvlBdb6XRVy7uOhiWZoQtfZMJjLj1tR kRzekrINqV1tnevsMYGNbi87+SEr9ka3B85mYTvYOFtkrOESKXodG9eCHWuobiR0AfdB07lOyNh VbeXGixkPiW/kXxSaR4akHI= Received: from mail.maildlp.com (unknown [172.19.163.200]) by canpmsgout08.his.huawei.com (SkyGuard) with ESMTPS id 4fC43x0N20zmV6s; Fri, 13 Feb 2026 15:46:21 +0800 (CST) Received: from kwepemf100008.china.huawei.com (unknown [7.202.181.222]) by mail.maildlp.com (Postfix) with ESMTPS id 788D24055B; Fri, 13 Feb 2026 15:51:01 +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; Fri, 13 Feb 2026 15:51:00 +0800 From: Zeng Heng To: , , , , , , CC: Subject: [PATCH] arm_mpam: Fix MPAM reset on resctrl unmount by clearing in_reset_state Date: Fri, 13 Feb 2026 15:50:54 +0800 Message-ID: <20260213075054.1574546-1-zengheng4@huawei.com> X-Mailer: git-send-email 2.25.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: kwepems100002.china.huawei.com (7.221.188.206) To kwepemf100008.china.huawei.com (7.202.181.222) Content-Type: text/plain; charset="utf-8" When resctrl is unmounted, MPAM components should be reset to default configurations to avoid impacting system performance. However, after a user updates MPAM configuration via mpam_apply_config(), the in_reset_state flag remains true, causing mpam_reset_ris() to skip the actual register restoration on subsequent resets. For example, after mounting resctrl and modifying the root group's schemata (e.g., changing MBMAX/MBMIN values), unmounting resctrl would leave the modified MPAM settings in hardware registers since mpam_reset_ris() returns early due to in_reset_state still being true. This results in persistent performance restrictions even after resctrl is umounted. Fix by clearing in_reset_state to false immediately after successful configuration application, ensuring that the next reset operation properly restores MPAM register defaults. Fixes: f188a36ca241 ("arm_mpam: Reset MSC controls from cpuhp callbacks") Signed-off-by: Zeng Heng Acked-by: Ben Horgan --- The in_reset_state state machine has been carefully reviewed, particularly the handling in mpam_cpu_online() where the flag is checked before applying configurations. in_reset_state indicates whether the RIS is currently using default configurations. This change aligns with the original design intent and does not introduce semantic breakage to existing state transitions. --- drivers/resctrl/mpam_devices.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/resctrl/mpam_devices.c b/drivers/resctrl/mpam_devices.c index 460ea98a1c92..044227ee033f 100644 --- a/drivers/resctrl/mpam_devices.c +++ b/drivers/resctrl/mpam_devices.c @@ -2932,6 +2932,7 @@ int mpam_apply_config(struct mpam_component *comp, u1= 6 partid, srcu_read_lock_held(&mpam_srcu)) { arg.ris =3D ris; mpam_touch_msc(msc, __write_config, &arg); + ris->in_reset_state =3D false; } mutex_unlock(&msc->cfg_lock); } -- 2.25.1