From nobody Tue Dec 16 03:21:11 2025 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.12]) (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 8376914F9CF for ; Thu, 5 Sep 2024 05:54:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.12 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1725515693; cv=none; b=ZZCgxqMGjyh3h4JgHCHg3f5NnZUshyppzV2Ok0bjUcQYgVYRsviFlMuL9VpfLbcvCDdR8fyzibgbrHYKRW17Qt/Md5cERcmoPiKNzlA4ZF+FNOT3+3hFjJF6soIh9FIYuE3EOkUFuV4wGUW7IVaveNPjC3wKfH2jX9MrkthOh60= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1725515693; c=relaxed/simple; bh=2Caot2V+L7brz3WAyt6qJA6b1XHoSY4/uaIi8Q1qaDA=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References; b=jAw678JL4cqPEwmPVABhgd6pKmAC0pkD44q0fXzkF3+Z2nTYv4a4tRZX83hbv55lsfwmaXWeTP/k0PnAnOYhZwmfBO7fayMDWfM0em9PtskHC4b9uwrPD6Pqf1CxnV2n9nirgsUqgsnm0pW11vQIVTPimMIFEMlFgb6Hax2BMog= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=JVr7T69J; arc=none smtp.client-ip=198.175.65.12 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="JVr7T69J" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1725515691; x=1757051691; h=from:to:cc:subject:date:message-id:in-reply-to: references; bh=2Caot2V+L7brz3WAyt6qJA6b1XHoSY4/uaIi8Q1qaDA=; b=JVr7T69JhtM1L2n0siqC0reZNIU8T9p6UNJb4p0sz2jrY+hbjo0seTWV gBzfyKvrpXxDvlezjc+HjxFMzaemxAazNKNG6t6CFhokf5fjgQQR2NHlD Mn8mS8V35naoAj2c6J76Ublv6oEhuDwAuqmjMhRDdhs8cZQIU3hGPvz3N vHqFVCWPoZpEov/cznsxbNrBUOfOlbbUsYzN8fjGqzLRXSF7GrL5DpAW4 pb8VVwCqlF2itwoke8rZEpg1kcVMUoiHRn4HmnTmxx5CCOvDk6XaThmSm fLbB/6cLlNnM6QlChz1OhIzVXqhvtOpf1V6g+wgTC2wrlzCYnTYDES9lk A==; X-CSE-ConnectionGUID: bc/5YEBcS4umaYLrYLiErQ== X-CSE-MsgGUID: uF/eM4EvSDiWjqF8inURJw== X-IronPort-AV: E=McAfee;i="6700,10204,11185"; a="35567190" X-IronPort-AV: E=Sophos;i="6.10,203,1719903600"; d="scan'208";a="35567190" Received: from orviesa004.jf.intel.com ([10.64.159.144]) by orvoesa104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Sep 2024 22:54:49 -0700 X-CSE-ConnectionGUID: Kh6A0Cq8QYeDpPnut8kWhA== X-CSE-MsgGUID: MBn4P9tVQBWCoJu6kN+jdQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.10,203,1719903600"; d="scan'208";a="70421555" Received: from ranerica-svr.sc.intel.com ([172.25.110.23]) by orviesa004.jf.intel.com with ESMTP; 04 Sep 2024 22:54:49 -0700 From: Ricardo Neri To: x86@kernel.org Cc: Andreas Herrmann , Catalin Marinas , Chen Yu , Len Brown , Radu Rendec , Pierre Gondois , Pu Wen , "Rafael J. Wysocki" , Sudeep Holla , Srinivas Pandruvada , Will Deacon , Zhang Rui , Nikolay Borisov , Huang Ying , Ricardo Neri , linux-kernel@vger.kernel.org Subject: [PATCH v6 1/4] cacheinfo: Check for null last-level cache info Date: Wed, 4 Sep 2024 23:00:33 -0700 Message-Id: <20240905060036.5655-2-ricardo.neri-calderon@linux.intel.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20240905060036.5655-1-ricardo.neri-calderon@linux.intel.com> References: <20240905060036.5655-1-ricardo.neri-calderon@linux.intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Before determining the validity of the last-level cache info, ensure that it has been allocated. Simply checking for non-zero cache_leaves() is not sufficient, as some architectures (e.g., Intel processors) have non-zero cache_leaves() before allocation. Dereferencing NULL cacheinfo can occur in update_per_cpu_data_slice_size(). This function iterates over all online CPUs. However, a CPU may have come online recently, but its cacheinfo may not have been allocated yet. Reviewed-by: Andreas Herrmann Reviewed-by: Sudeep Holla Tested-by: Andreas Herrmann Signed-off-by: Ricardo Neri --- Cc: Andreas Herrmann Cc: Catalin Marinas Cc: Chen Yu Cc: Huang Ying Cc: Len Brown Cc: Nikolay Borisov Cc: Radu Rendec Cc: Pierre Gondois Cc: Pu Wen Cc: "Rafael J. Wysocki" Cc: Sudeep Holla Cc: Srinivas Pandruvada Cc: Will Deacon Cc: Zhang Rui Cc: linux-arm-kernel@lists.infradead.org Cc: stable@vger.kernel.org # 6.3+ --- Changes since v5: * Added Reviewed-by and Tested-by tags from Andreas. Thanks! Changes since v4: * Combined checks for per_cpu_cacheinfo() and cache_leaves() in a single line. (Sudeep) * Added Reviewed-by tag from Sudeep. Thanks! Changes since v3: * Introduced this patch. Changes since v2: * N/A Changes since v1: * N/A --- The dereference of a NULL cacheinfo is not observed today because cache_leaves(cpu) is zero until after init_cache_level() is called (during the CPU hotplug callback). A subsequent changeset will set the number of cache leaves earlier and the NULL-pointer dereference will be observed. --- drivers/base/cacheinfo.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/base/cacheinfo.c b/drivers/base/cacheinfo.c index 23b8cba4a2a3..77f2e0f91589 100644 --- a/drivers/base/cacheinfo.c +++ b/drivers/base/cacheinfo.c @@ -58,7 +58,7 @@ bool last_level_cache_is_valid(unsigned int cpu) { struct cacheinfo *llc; =20 - if (!cache_leaves(cpu)) + if (!cache_leaves(cpu) || !per_cpu_cacheinfo(cpu)) return false; =20 llc =3D per_cpu_cacheinfo_idx(cpu, cache_leaves(cpu) - 1); --=20 2.34.1 From nobody Tue Dec 16 03:21:11 2025 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.12]) (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 EB00A188A2E for ; Thu, 5 Sep 2024 05:54:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.12 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1725515693; cv=none; b=UT/hRzFQBP/ul2AZqeL7ecjMrgB3rnBb0og2tKVuAVTK+ZMlA1O33M2i3eYfBt1sIk5Qj4TzIDQcsXWWuPgSa5ugRvkmNl/4Nn8RnWeVWwTBItjAk6HnB8XNQeN1jUw/N0AtJHnB+Bc+3Rii1SCyOGd676QaNfcfxqPaSxUNPOc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1725515693; c=relaxed/simple; bh=sSDZ72j5OaTGAMgOsBORGAz3e3oilXZd4uRNFw7vQH4=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References; b=lgzgQGdnO172obUo9pb5hOeDfl82R6dzvNQ86y7gshOS7jjyDfEbXfwCddIl69fr4yPIjnD1mHA+odJryOoxn+D1FXgWhT2VMtQxaJYwQoW5uScnOkBCDkPC+v12FxANHw6zPmxyPHwIMzetMjl1Qlaf/tZWFonDMv3Ha8YfJ4A= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=LEuv/PNK; arc=none smtp.client-ip=198.175.65.12 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="LEuv/PNK" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1725515692; x=1757051692; h=from:to:cc:subject:date:message-id:in-reply-to: references; bh=sSDZ72j5OaTGAMgOsBORGAz3e3oilXZd4uRNFw7vQH4=; b=LEuv/PNKsseZ5OzQc3LatnIGFmKLhQeVF/WRG0CTu1ZZWWP6gIPoVMVJ eZLNvLZUDoKSUhJvS/b/tBPXjC8ixhQUB8AftUt3vkl/1cVOlH2phSTeZ /96RBQzQmNK7ndBobHhp7W5cXBYbh3ilB/35OafPc0aLa+UWcoFaz+mtT lkLqf5aihKwkS0WCRrCMeLL2oZ5LhjVydAU+vZrnnky9W7brQNuPhK+yU OPt5mlwFCI2dS4sN0059jizXB+V7j4ciPPT9EdirecTJTjk0Nc3Og9gqS LBtD6QgZaU9N6LssnZ3rIWRDjh8PZJKHA9wVhVMy8Ct+9+oVMfq0cJNHh Q==; X-CSE-ConnectionGUID: VZa8Fc0nSS6RwGzHaamSsQ== X-CSE-MsgGUID: 9kaAqzbBTqeYfDer7f4Cfw== X-IronPort-AV: E=McAfee;i="6700,10204,11185"; a="35567196" X-IronPort-AV: E=Sophos;i="6.10,203,1719903600"; d="scan'208";a="35567196" Received: from orviesa004.jf.intel.com ([10.64.159.144]) by orvoesa104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Sep 2024 22:54:50 -0700 X-CSE-ConnectionGUID: K82uOnlKTyOK/YMZdx8UHQ== X-CSE-MsgGUID: 3xUs3fTJQASPpPanhB+uWQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.10,203,1719903600"; d="scan'208";a="70421565" Received: from ranerica-svr.sc.intel.com ([172.25.110.23]) by orviesa004.jf.intel.com with ESMTP; 04 Sep 2024 22:54:50 -0700 From: Ricardo Neri To: x86@kernel.org Cc: Andreas Herrmann , Catalin Marinas , Chen Yu , Len Brown , Radu Rendec , Pierre Gondois , Pu Wen , "Rafael J. Wysocki" , Sudeep Holla , Srinivas Pandruvada , Will Deacon , Zhang Rui , Nikolay Borisov , Huang Ying , Ricardo Neri , linux-kernel@vger.kernel.org Subject: [PATCH v6 2/4] cacheinfo: Allocate memory during CPU hotplug if not done from the primary CPU Date: Wed, 4 Sep 2024 23:00:34 -0700 Message-Id: <20240905060036.5655-3-ricardo.neri-calderon@linux.intel.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20240905060036.5655-1-ricardo.neri-calderon@linux.intel.com> References: <20240905060036.5655-1-ricardo.neri-calderon@linux.intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Commit 5944ce092b97 ("arch_topology: Build cacheinfo from primary CPU") adds functionality that architectures can use to optionally allocate and build cacheinfo early during boot. Commit 6539cffa9495 ("cacheinfo: Add arch specific early level initializer") lets secondary CPUs correct (and reallocate memory) cacheinfo data if needed. If the early build functionality is not used and cacheinfo does not need correction, memory for cacheinfo is never allocated. x86 does not use the early build functionality. Consequently, during the cacheinfo CPU hotplug callback, last_level_cache_is_valid() attempts to dereference a NULL pointer: BUG: kernel NULL pointer dereference, address: 0000000000000100 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not present page PGD 0 P4D 0 Oops: 0000 [#1] PREEPMT SMP NOPTI CPU: 0 PID 19 Comm: cpuhp/0 Not tainted 6.4.0-rc2 #1 RIP: 0010: last_level_cache_is_valid+0x95/0xe0a Allocate memory for cacheinfo during the cacheinfo CPU hotplug callback if not done earlier. Reviewed-by: Andreas Herrmann Reviewed-by: Nikolay Borisov Reviewed-by: Radu Rendec Reviewed-by: Sudeep Holla Tested-by: Andreas Herrmann Fixes: 6539cffa9495 ("cacheinfo: Add arch specific early level initializer") Signed-off-by: Ricardo Neri --- Cc: Andreas Herrmann Cc: Catalin Marinas Cc: Chen Yu Cc: Huang Ying Cc: Len Brown Cc: Nikolay Borisov Cc: Radu Rendec Cc: Pierre Gondois Cc: Pu Wen Cc: "Rafael J. Wysocki" Cc: Sudeep Holla Cc: Srinivas Pandruvada Cc: Will Deacon Cc: Zhang Rui Cc: linux-arm-kernel@lists.infradead.org Cc: stable@vger.kernel.org # 6.3+ --- The motivation for commit 5944ce092b97 was to prevent a BUG splat in PREEMPT_RT kernels during memory allocation. This splat is not observed on x86 because the memory allocation for cacheinfo happens in detect_cache_attributes() from the cacheinfo CPU hotplug callback. The dereference of a NULL pointer is not observed today because cache_leaves(cpu) is zero until after init_cache_level() is called (also during the CPU hotplug callback). A subsequent changeset will set the number of cache leaves earlier and the NULL-pointer dereference will be observed. --- Changes since v5: * Fixed nonsensical subject (Nikolay). * Added Reviewed-by tag from Nikolay and Andreas. Thanks! * Added Tested-by tag from Andreas. Thanks! Changes since v4: * None Changes since v3: * Added Reviewed-by tag from Radu and Sudeep. Thanks! Changes since v2: * Introduced this patch. Changes since v1: * N/A --- drivers/base/cacheinfo.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/base/cacheinfo.c b/drivers/base/cacheinfo.c index 77f2e0f91589..0332148691f9 100644 --- a/drivers/base/cacheinfo.c +++ b/drivers/base/cacheinfo.c @@ -554,7 +554,11 @@ static inline int init_level_allocate_ci(unsigned int = cpu) */ ci_cacheinfo(cpu)->early_ci_levels =3D false; =20 - if (cache_leaves(cpu) <=3D early_leaves) + /* + * Some architectures (e.g., x86) do not use early initialization. + * Allocate memory now in such case. + */ + if (cache_leaves(cpu) <=3D early_leaves && per_cpu_cacheinfo(cpu)) return 0; =20 kfree(per_cpu_cacheinfo(cpu)); --=20 2.34.1 From nobody Tue Dec 16 03:21:11 2025 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.12]) (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 2D203189523 for ; Thu, 5 Sep 2024 05:54:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.12 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1725515694; cv=none; b=r9qYmkha8z5UdZTnNrHVByeNsWWtVqq5qms1pgSU+Hf5rb9EGnMa0TS1PwUo0O9/9IroRmfCGDyflidMV6Wiw0DTi+GDvEFY2WA0EWHB8C/ftTJzwG4+qED3JnNxMv6XCXnUFJcxWsdy2FnxOFSBf+t9hsOv2g06Mj3EWUa+nDs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1725515694; c=relaxed/simple; bh=PcJl2+cEF+bRzQuqeAjuEPnGZ6EOblSbeWsQbeMWdEI=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References; b=SVfxCt3WZ1BBY7LEg6yOZc2VzlzC2scqYpLtinmMSeCeGm3A/LOWE8bn7gRmMSfXCXE4T3O6umEYPQpiBu7oNZ2jeVk5cFTLmt7+bx4C5Zevt0SXv9L62PYNrCX2dTEs4xoWqNVv7D2LmXrqstHDjQD9EMEyGQYMne0zKL1dtMA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=Xg2NJM38; arc=none smtp.client-ip=198.175.65.12 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="Xg2NJM38" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1725515693; x=1757051693; h=from:to:cc:subject:date:message-id:in-reply-to: references; bh=PcJl2+cEF+bRzQuqeAjuEPnGZ6EOblSbeWsQbeMWdEI=; b=Xg2NJM38VPjO0X5gD+sRI9oQruV079PUzW0Ch67xvGQaSnhqbljhiD+h AsQIBwm0eedmPYqwKkxKLQKss7CQMWerc5FuZEI4ifcfwKhyrRUSFelXT uYhV6Zk0Z3nPXImcJ+JlAXaA8gM6QiNXu0urjlLfR3gQPrJmFr/5kv/Ku sSEG/6HYO+c4NBI/Vfx/6szkzzqgNOxlGETYcXr7El7GF6gsL1LhIFfTj iCz6T//QFMiCrmUNlrKnE26swKL05A2+bCdG0TWpF5mKn0/3o/eK3Rfyi RU4jQG+HMMqKsIqAlOoZil78FCL4NiTk/es0Qut6VhSKDaB1FGLBhoIul g==; X-CSE-ConnectionGUID: SGROWVHqTfioH6/iIOv0qg== X-CSE-MsgGUID: ow1zMiIUQgqJH+lZDrtkUw== X-IronPort-AV: E=McAfee;i="6700,10204,11185"; a="35567202" X-IronPort-AV: E=Sophos;i="6.10,203,1719903600"; d="scan'208";a="35567202" Received: from orviesa004.jf.intel.com ([10.64.159.144]) by orvoesa104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Sep 2024 22:54:51 -0700 X-CSE-ConnectionGUID: mKe6wBHwQtOHCbURh/kOqQ== X-CSE-MsgGUID: aZyFmc0ASqCt0tCG7G7Yog== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.10,203,1719903600"; d="scan'208";a="70421569" Received: from ranerica-svr.sc.intel.com ([172.25.110.23]) by orviesa004.jf.intel.com with ESMTP; 04 Sep 2024 22:54:50 -0700 From: Ricardo Neri To: x86@kernel.org Cc: Andreas Herrmann , Catalin Marinas , Chen Yu , Len Brown , Radu Rendec , Pierre Gondois , Pu Wen , "Rafael J. Wysocki" , Sudeep Holla , Srinivas Pandruvada , Will Deacon , Zhang Rui , Nikolay Borisov , Huang Ying , Ricardo Neri , linux-kernel@vger.kernel.org Subject: [PATCH v6 3/4] x86/cacheinfo: Delete global num_cache_leaves Date: Wed, 4 Sep 2024 23:00:35 -0700 Message-Id: <20240905060036.5655-4-ricardo.neri-calderon@linux.intel.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20240905060036.5655-1-ricardo.neri-calderon@linux.intel.com> References: <20240905060036.5655-1-ricardo.neri-calderon@linux.intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Linux remembers cpu_cachinfo::num_leaves per CPU, but x86 initializes all CPUs from the same global "num_cache_leaves". This is erroneous on systems such as Meteor Lake, where each CPU has a distinct num_leaves value. Delete the global "num_cache_leaves" and initialize num_leaves on each CPU. Reviewed-by: Andreas Herrmann Reviewed-by: Len Brown Reviewed-by: Nikolay Borisov Tested-by: Andreas Herrmann Signed-off-by: Ricardo Neri --- Cc: Andreas Herrmann Cc: Catalin Marinas Cc: Chen Yu Cc: Huang Ying Cc: Len Brown Cc: Nikolay Borisov Cc: Radu Rendec Cc: Pierre Gondois Cc: Pu Wen Cc: "Rafael J. Wysocki" Cc: Sudeep Holla Cc: Srinivas Pandruvada Cc: Will Deacon Cc: Zhang Rui Cc: linux-arm-kernel@lists.infradead.org Cc: stable@vger.kernel.org # 6.3+ --- After this change, all CPUs will traverse CPUID leaf 0x4 when booted for the first time. On systems with symmetric cache topologies this is useless work. Creating a list of processor models that have asymmetric cache topologies was considered. The burden of maintaining such list would outweigh the performance benefit of skipping this extra step. --- Changes since v5: * Reordered the arguments of set_num_cache_leaves() for readability. (Nikolay) * Added Reviewed-by tag from Nikolay and Andreas. Thanks! * Added Tested-by tag from Andreas. Thanks! Changes since v4: * None Changes since v3: * Rebased on v6.7-rc5. Changes since v2: * None Changes since v1: * Do not make num_cache_leaves a per-CPU variable. Instead, reuse the existing per-CPU ci_cpu_cacheinfo variable. (Dave Hansen) --- arch/x86/kernel/cpu/cacheinfo.c | 44 +++++++++++++++++++-------------- 1 file changed, 26 insertions(+), 18 deletions(-) diff --git a/arch/x86/kernel/cpu/cacheinfo.c b/arch/x86/kernel/cpu/cacheinf= o.c index 392d09c936d6..182cacd772b8 100644 --- a/arch/x86/kernel/cpu/cacheinfo.c +++ b/arch/x86/kernel/cpu/cacheinfo.c @@ -178,7 +178,16 @@ struct _cpuid4_info_regs { struct amd_northbridge *nb; }; =20 -static unsigned short num_cache_leaves; +static inline unsigned int get_num_cache_leaves(unsigned int cpu) +{ + return get_cpu_cacheinfo(cpu)->num_leaves; +} + +static inline void +set_num_cache_leaves(unsigned int cpu, unsigned int nr_leaves) +{ + get_cpu_cacheinfo(cpu)->num_leaves =3D nr_leaves; +} =20 /* AMD doesn't have CPUID4. Emulate it here to report the same information to the user. This makes some assumptions about the machine: @@ -718,19 +727,21 @@ void cacheinfo_hygon_init_llc_id(struct cpuinfo_x86 *= c) void init_amd_cacheinfo(struct cpuinfo_x86 *c) { =20 + unsigned int cpu =3D c->cpu_index; + if (boot_cpu_has(X86_FEATURE_TOPOEXT)) { - num_cache_leaves =3D find_num_cache_leaves(c); + set_num_cache_leaves(cpu, find_num_cache_leaves(c)); } else if (c->extended_cpuid_level >=3D 0x80000006) { if (cpuid_edx(0x80000006) & 0xf000) - num_cache_leaves =3D 4; + set_num_cache_leaves(cpu, 4); else - num_cache_leaves =3D 3; + set_num_cache_leaves(cpu, 3); } } =20 void init_hygon_cacheinfo(struct cpuinfo_x86 *c) { - num_cache_leaves =3D find_num_cache_leaves(c); + set_num_cache_leaves(c->cpu_index, find_num_cache_leaves(c)); } =20 void init_intel_cacheinfo(struct cpuinfo_x86 *c) @@ -742,19 +753,19 @@ void init_intel_cacheinfo(struct cpuinfo_x86 *c) unsigned int l2_id =3D 0, l3_id =3D 0, num_threads_sharing, index_msb; =20 if (c->cpuid_level > 3) { - static int is_initialized; - - if (is_initialized =3D=3D 0) { - /* Init num_cache_leaves from boot CPU */ - num_cache_leaves =3D find_num_cache_leaves(c); - is_initialized++; - } + /* + * There should be at least one leaf. A non-zero value means + * that the number of leaves has been initialized. + */ + if (!get_num_cache_leaves(c->cpu_index)) + set_num_cache_leaves(c->cpu_index, + find_num_cache_leaves(c)); =20 /* * Whenever possible use cpuid(4), deterministic cache * parameters cpuid leaf to find the cache details */ - for (i =3D 0; i < num_cache_leaves; i++) { + for (i =3D 0; i < get_num_cache_leaves(c->cpu_index); i++) { struct _cpuid4_info_regs this_leaf =3D {}; int retval; =20 @@ -790,14 +801,14 @@ void init_intel_cacheinfo(struct cpuinfo_x86 *c) * Don't use cpuid2 if cpuid4 is supported. For P4, we use cpuid2 for * trace cache */ - if ((num_cache_leaves =3D=3D 0 || c->x86 =3D=3D 15) && c->cpuid_level > 1= ) { + if ((!get_num_cache_leaves(c->cpu_index) || c->x86 =3D=3D 15) && c->cpuid= _level > 1) { /* supports eax=3D2 call */ int j, n; unsigned int regs[4]; unsigned char *dp =3D (unsigned char *)regs; int only_trace =3D 0; =20 - if (num_cache_leaves !=3D 0 && c->x86 =3D=3D 15) + if (get_num_cache_leaves(c->cpu_index) && c->x86 =3D=3D 15) only_trace =3D 1; =20 /* Number of times to iterate */ @@ -993,12 +1004,9 @@ int init_cache_level(unsigned int cpu) { struct cpu_cacheinfo *this_cpu_ci =3D get_cpu_cacheinfo(cpu); =20 - if (!num_cache_leaves) - return -ENOENT; if (!this_cpu_ci) return -EINVAL; this_cpu_ci->num_levels =3D 3; - this_cpu_ci->num_leaves =3D num_cache_leaves; return 0; } =20 --=20 2.34.1 From nobody Tue Dec 16 03:21:11 2025 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.12]) (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 A1B601898EB for ; Thu, 5 Sep 2024 05:54:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.12 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1725515695; cv=none; b=uKTMHhYh8ZERv5sGftZhndUf9tg8Au8Cj8oER9bTu94gnQ4twxIRQpIe02p5sDSZ2DeVU22pvYtSsHz7a9GtBgP+a5/yHtJpbet/02ZSu8weGwaOEtCcSuynq3B0RsqzZ1j0fy1mMp5Y0pveoDvIyqmzyoGiJywxqdPesCUpVmY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1725515695; c=relaxed/simple; bh=IoEbX8ulS4nbWpyE+m+Af6Xb8Zi/WPdDMRA2qcoZ2Vk=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References; b=q2tIjMZ/yV2pQkB94IDx9JKz1ggiugzBX1mXlGFeq+sjGmb/GMoZbbc88od9+hkzHE/dEB6KWRJX8Xshy1/o96K1I6upSpEo9sulbHFz9cHqZXzOrE31zlhUkkIHlKvHx0SLFMg3UyEUM9Bsy/OvOv8NuYyq+6h+EmA1ILnkXyI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=nNv3pHrD; arc=none smtp.client-ip=198.175.65.12 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="nNv3pHrD" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1725515693; x=1757051693; h=from:to:cc:subject:date:message-id:in-reply-to: references; bh=IoEbX8ulS4nbWpyE+m+Af6Xb8Zi/WPdDMRA2qcoZ2Vk=; b=nNv3pHrDfrzXlOnZvAR1e9xMm8gkclfFzukasj98PAOsHa+AgrePqtgP FTLBTPn4OKUQZbiMvK4+uPS2gAyOthyUp8pxSRwVjq3cl1l7F4ZRG0Aed vK3bqQBXgRCuGp6NgDoaoZqzxKMzyfTqW4AzPFmmarvCiTEuPT1rq2IxB q2ka3oHR3bvLP/aq6YRDpMGZZsh1qlDhRhXiT6kvb+xvU0kFK9IZOGNSb CRoxO8yGs+BbwTZ6ExiCjgjJwZDfdwS6Qr0gzOGIHuO3XQ6smyemPOTUD Ron7buylPA22QmWPZ8lq9yAd4t8E0FqrMR6XFy8Kkev8r0oXBOQYksawF g==; X-CSE-ConnectionGUID: Zf2HuIOnSL2OAPo0gFRBQw== X-CSE-MsgGUID: 3Pvzm9H2Q3C8Rbzqk5sVOA== X-IronPort-AV: E=McAfee;i="6700,10204,11185"; a="35567211" X-IronPort-AV: E=Sophos;i="6.10,203,1719903600"; d="scan'208";a="35567211" Received: from orviesa004.jf.intel.com ([10.64.159.144]) by orvoesa104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Sep 2024 22:54:51 -0700 X-CSE-ConnectionGUID: /KnsrvVgRESsnoDRbQ1YLg== X-CSE-MsgGUID: MIeozWI0R2a6JzHwHSOiOg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.10,203,1719903600"; d="scan'208";a="70421572" Received: from ranerica-svr.sc.intel.com ([172.25.110.23]) by orviesa004.jf.intel.com with ESMTP; 04 Sep 2024 22:54:50 -0700 From: Ricardo Neri To: x86@kernel.org Cc: Andreas Herrmann , Catalin Marinas , Chen Yu , Len Brown , Radu Rendec , Pierre Gondois , Pu Wen , "Rafael J. Wysocki" , Sudeep Holla , Srinivas Pandruvada , Will Deacon , Zhang Rui , Nikolay Borisov , Huang Ying , Ricardo Neri , linux-kernel@vger.kernel.org Subject: [PATCH v6 4/4] x86/cacheinfo: Clean out init_cache_level() Date: Wed, 4 Sep 2024 23:00:36 -0700 Message-Id: <20240905060036.5655-5-ricardo.neri-calderon@linux.intel.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20240905060036.5655-1-ricardo.neri-calderon@linux.intel.com> References: <20240905060036.5655-1-ricardo.neri-calderon@linux.intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" init_cache_level() no longer has a purpose on x86. It no longer needs to set num_leaves, and it never had to set num_levels, which was unnecessary on x86. Replace it with "return 0" simply to override the weak function, which would return an error. Reviewed-by: Andreas Herrmann Reviewed-by: Len Brown Reviewed-by: Nikolay Borisov Tested-by: Andreas Herrmann Signed-off-by: Ricardo Neri --- Cc: Andreas Herrmann Cc: Catalin Marinas Cc: Chen Yu CC: Huang Ying Cc: Len Brown Cc: Nikolay Borisov Cc: Radu Rendec Cc: Pierre Gondois Cc: Pu Wen Cc: "Rafael J. Wysocki" Cc: Sudeep Holla Cc: Srinivas Pandruvada Cc: Will Deacon Cc: Zhang Rui Cc: linux-arm-kernel@lists.infradead.org Cc: stable@vger.kernel.org # 6.3+ --- Changes since v5: * Added Reviewed-by tag from Nikolay and Andreas. Thanks! Changes since v4: * None Changes since v3: * Rebased on v6.7-rc5. Changes since v2: * None Changes since v1: * Introduced this patch. --- arch/x86/kernel/cpu/cacheinfo.c | 5 ----- 1 file changed, 5 deletions(-) diff --git a/arch/x86/kernel/cpu/cacheinfo.c b/arch/x86/kernel/cpu/cacheinf= o.c index 182cacd772b8..2a37f14cc6b1 100644 --- a/arch/x86/kernel/cpu/cacheinfo.c +++ b/arch/x86/kernel/cpu/cacheinfo.c @@ -1002,11 +1002,6 @@ static void ci_leaf_init(struct cacheinfo *this_leaf, =20 int init_cache_level(unsigned int cpu) { - struct cpu_cacheinfo *this_cpu_ci =3D get_cpu_cacheinfo(cpu); - - if (!this_cpu_ci) - return -EINVAL; - this_cpu_ci->num_levels =3D 3; return 0; } =20 --=20 2.34.1