From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from canpmsgout03.his.huawei.com (canpmsgout03.his.huawei.com [113.46.200.218]) (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 2543A52F8B for ; Sat, 21 Mar 2026 04:11:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.218 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774066292; cv=none; b=nC/4xBM2btU5/5x8qrWuBC4zGyEMaRWkuObDeksb/DDFUMlPmGmkel/KhGpk3gJ17gX/7SkYvYVlCHLG3jqob7DKnKtMB/YGTYP0sMSgX4Nmmgm9Ifxs5rs/Q6DyhlQyu7e49mLFokNNmUf7W4e5VRdiIJuntXTIXaucRnrXa+E= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774066292; c=relaxed/simple; bh=6U31g+EraUAK97Y71mJvOpQNJS117aG4JqJX7nltBq8=; h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From: In-Reply-To:Content-Type; b=tJyyviLpCfRo9Y1kUZ9D14kpTS6l/hXC+1W4ErmU45MJvizdmsFJ+1l9unZMihg3KSqH2Xl72oEQ8xoSnRNRcw/sFHDYH3rMQbL5+dkuNancSKD0IVZgca3Ydu7MNVXjhZIvPQf0PmfhjIhw1EiFb6Wufy1n9AYHQtMvou9OvwA= 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=IjgQhM5J; arc=none smtp.client-ip=113.46.200.218 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="IjgQhM5J" dkim-signature: v=1; a=rsa-sha256; d=h-partners.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=svg9lstZoCmgf79R6w299QC6MoXKsF66slNuoKmi7BQ=; b=IjgQhM5JOSC7J0y13RoPqsGy8ZFf8OgYOwLqp3DW1tW4cnV+8N7ZMZT5bN6cEHja34zIag4js lxRsCsO5lRV+i0LxCqWO9jJSuP6Mi7qEEwkkoxDU+htoG1EzcexaM19AtQOaoCTWdk8jyIG2Zka kRX75eoEpElyYgwucAkkdfE= Received: from mail.maildlp.com (unknown [172.19.162.197]) by canpmsgout03.his.huawei.com (SkyGuard) with ESMTPS id 4fd5T174cNzpSv2; Sat, 21 Mar 2026 12:05:57 +0800 (CST) Received: from kwepemf100008.china.huawei.com (unknown [7.202.181.222]) by mail.maildlp.com (Postfix) with ESMTPS id 7B6E540363; Sat, 21 Mar 2026 12:11:26 +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 12:11:25 +0800 Message-ID: Date: Sat, 21 Mar 2026 12:11:24 +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 To: Ben Horgan , , , , CC: , , , , , , , , , References: <20260317132141.1272506-1-zengheng4@huawei.com> <20260317132141.1272506-2-zengheng4@huawei.com> From: Zeng Heng In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: kwepems500002.china.huawei.com (7.221.188.17) To kwepemf100008.china.huawei.com (7.202.181.222) 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. Best Regards, Zeng Heng > > Thanks, > > Ben > >> fix addresses the immediate correctness issue with minimal churn. >> >> Signed-off-by: Zeng Heng