From nobody Fri Dec 19 07:32:36 2025 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 45450169AFD for ; Fri, 14 Jun 2024 15:01:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1718377275; cv=none; b=R4dWFjoOiCrqJsO2px/+NIRlq8uGqiHbLPOOFkvvz7cM3P01SkdToi0dH+xzeCnOSf/oTyN6+HyTF8Wd2CSmzWWpCWnvg+8oEf2cnGHrifN77pOBReOYR9VNbhfKuRes9bBbVZ1l/HKHNTvqdlANkXKzfNx43QMj21K69N3y5v4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1718377275; c=relaxed/simple; bh=DogtMNNuGDoRVa4ZPRiH4Ilmpg5SKkCjqSLSfxc6uUI=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=Ia8Q8E9+aR8AQ/5pnRg7HJHeWJlZMieXiMl+bcZjd/1XPwJgzzMXd4SdNnYbPNSE0cgki582YJZHpiIld0/jB2PL92JIaY6f2eDWbamhAkV3GQ0cXEWKn3+AsIkE6KbhRpSvPHSEOl4VsBJRre2enpJtNIMbwKbQmYLsJY/4G6s= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id ADA3FFEC; Fri, 14 Jun 2024 08:01:36 -0700 (PDT) Received: from merodach.members.linode.com (usa-sjc-mx-foss1.foss.arm.com [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 0717B3F5A1; Fri, 14 Jun 2024 08:01:08 -0700 (PDT) From: James Morse To: x86@kernel.org, linux-kernel@vger.kernel.org Cc: Fenghua Yu , Reinette Chatre , Thomas Gleixner , Ingo Molnar , Borislav Petkov , H Peter Anvin , Babu Moger , James Morse , shameerali.kolothum.thodi@huawei.com, D Scott Phillips OS , carl@os.amperecomputing.com, lcherian@marvell.com, bobo.shaobowang@huawei.com, tan.shaopeng@fujitsu.com, baolin.wang@linux.alibaba.com, Jamie Iles , Xin Hao , peternewman@google.com, dfustini@baylibre.com, amitsinght@marvell.com, David Hildenbrand , Rex Nie , Dave Martin , Shaopeng Tan Subject: [PATCH v3 01/38] x86/resctrl: Fix allocation of cleanest CLOSID on platforms with no monitors Date: Fri, 14 Jun 2024 14:59:56 +0000 Message-Id: <20240614150033.10454-2-james.morse@arm.com> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20240614150033.10454-1-james.morse@arm.com> References: <20240614150033.10454-1-james.morse@arm.com> 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 Content-Type: text/plain; charset="utf-8" commit 6eac36bb9eb0 ("x86/resctrl: Allocate the cleanest CLOSID by searching closid_num_dirty_rmid") added logic that causes resctrl to search for the CLOSID with the fewest dirty cache lines when creating a new control group, if requested by the arch code. This depends on the values read from the llc_occupancy counters. The logic is applicable to architectures where the CLOSID effectively forms part of the monitoring identifier and so do not allow complete freedom to choose an unused monitoring identifier for a given CLOSID. This support missed that some platforms may not have these counters. This causes a NULL pointer dereference when creating a new control group as the array was not allocated by dom_data_init(). As this feature isn't necessary on platforms that don't have cache occupancy monitors, add this to the check that occurs when a new control group is allocated. The existing code is not selected by any upstream platform, it makes no sense to backport this patch to stable. Fixes: 6eac36bb9eb0 ("x86/resctrl: Allocate the cleanest CLOSID by searchin= g closid_num_dirty_rmid") Signed-off-by: James Morse Tested-by: Peter Newman Tested-by: Shaopeng Tan Reviewed-by: David Hildenbrand --- Changes since v1: * [Commit message only] Reword the first paragraph to make it clear that the issue being fixed wasn't directly associated with addition of a Kconfig option. (Actually, the option is not in Kconfig yet, and gets added later in this series.) --- arch/x86/kernel/cpu/resctrl/rdtgroup.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/x86/kernel/cpu/resctrl/rdtgroup.c b/arch/x86/kernel/cpu/r= esctrl/rdtgroup.c index 02f213f1c51c..d02f4c97e40f 100644 --- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c +++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c @@ -149,7 +149,8 @@ static int closid_alloc(void) =20 lockdep_assert_held(&rdtgroup_mutex); =20 - if (IS_ENABLED(CONFIG_RESCTRL_RMID_DEPENDS_ON_CLOSID)) { + if (IS_ENABLED(CONFIG_RESCTRL_RMID_DEPENDS_ON_CLOSID) && + is_llc_occupancy_enabled()) { cleanest_closid =3D resctrl_find_cleanest_closid(); if (cleanest_closid < 0) return cleanest_closid; --=20 2.39.2