From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from canpmsgout10.his.huawei.com (canpmsgout10.his.huawei.com [113.46.200.225]) (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 D6C4F317177 for ; Sat, 21 Mar 2026 06:39:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.225 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774075187; cv=none; b=FXpH3nNwDKuwPgciwMR3mFNUXMolAt+FkyTwQaVgp9/I5gmHIiwkzvMAqIpo0SRZCYPo7MMoazxpW6flg/vNDcCPF0ziy4q+o/SbEZTw5LZSVOKiXMjWCjJ0zy5c3A7f8JyXammPEzhH0r9ITICVv2OGCKajlmiUkvnWqrGnIH8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774075187; c=relaxed/simple; bh=LB/HYtzFVqxjrfT4QIVgH/ZmwpsbZd2+6MkHNprUx14=; h=Message-ID:Date:MIME-Version:Subject:From:To:CC:References: In-Reply-To:Content-Type; b=hxe+CpnfJbFIlt2Lj6dHlKnyrLaH6BNIFJbT/aFRzDngzrc/fC0yZOwGkAWpfZpc1ZJiFLZ9+G0UbJek1Ygrd/wUkCnxxBRPzqWeq2Vpo6r2rA+Rq8ndYfylpGwALPv5ICt/TzBh5eNqJ4TZ5T0xekW3u1BrhYrlfhOf2mbTphs= 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=qYNVNMNY; arc=none smtp.client-ip=113.46.200.225 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="qYNVNMNY" dkim-signature: v=1; a=rsa-sha256; d=h-partners.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=ADAA6qkUc7z5N9WoIMZ+8oKZE9CAT/C2DXcCCtIAMvk=; b=qYNVNMNYgsN/61j5jxNm210zUDxyHOiT/Boo7B2YYoxMtT83KJ3FeQkUvTWJVcFekFmfqUkDR baLDzR+3HE1TcJah1ikF067BpvwEXAXVTpy+uGGAgPH9Hj9yjnjv0tK75UoGzrrdxbW91B1gQr5 IYYjbh2+mgpR/bYKfWKmK14= Received: from mail.maildlp.com (unknown [172.19.163.200]) by canpmsgout10.his.huawei.com (SkyGuard) with ESMTPS id 4fd8lN2sDWz1K96T; Sat, 21 Mar 2026 14:33:36 +0800 (CST) Received: from kwepemf100008.china.huawei.com (unknown [7.202.181.222]) by mail.maildlp.com (Postfix) with ESMTPS id 2BC5740563; Sat, 21 Mar 2026 14:39:37 +0800 (CST) Received: from [10.174.179.37] (10.174.179.37) 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; Sat, 21 Mar 2026 14:39:35 +0800 Message-ID: Date: Sat, 21 Mar 2026 14:39:35 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Subject: Re: [PATCH v3 1/9] fs/resctrl: Fix MPAM Partid parsing errors by preserving CDP state during umount Content-Language: en-US From: Zeng Heng To: Ben Horgan , , , , CC: , , , , , , , , , References: <20260317132141.1272506-1-zengheng4@huawei.com> <20260317132141.1272506-2-zengheng4@huawei.com> In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: kwepems200002.china.huawei.com (7.221.188.68) To kwepemf100008.china.huawei.com (7.202.181.222) On 2026/3/21 12:11, Zeng Heng wrote: > Hi Ben, > > On 2026/3/21 1:07, Ben Horgan wrote: >> 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. > > Yes, this would indeed weaken MPAM's guarantee for clean RMIDs. > > Hopefully, no one is doing this in production, repeatedly switching > resctrl mount modes while monitoring workloads (which sounds more like > testing to me), and still expecting strict guarantees of clean RMID > allocation. > >> >>> 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? > > > In follow-up patches, resctrl_arch_rmid_idx_encode() also needs to > depend on the CDP state because it needs to check out the intpartid and > reqpartid. Between remount sessions, RMIDs residing in limbo also have a > parsing error issue. > > For this reason, had to make this patch as a prerequisite fix in the patch series. Best Regards, Zeng Heng