From nobody Sat Feb 7 08:43:04 2026 Received: from out-184.mta0.migadu.com (out-184.mta0.migadu.com [91.218.175.184]) (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 80DB6330D34 for ; Mon, 20 Oct 2025 17:37:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.184 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1760981875; cv=none; b=KVCvHdN6ZYu+rYlAFido+JtVyzjTLVj4qGna0/hVNzPCGTTo1gVr8mwcISUze9rg/W85Z/EE+Kcr2MZtm7F/oTTfRxNWTz3UiNfwoRhY5eYBenraG7KDs0nBHSrMsXNd2+Xw7nm1egJVq91Cehuk+vSqHYypCEKFyXjpun5++HI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1760981875; c=relaxed/simple; bh=spzmXTwXQMCw0dXOjAbfUadG6yGJaimkFswvX5WHPw8=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=NgY7jb5E2EwMoSjXYQ/XwMQ7ALNBTMiIIXbxgE8eCP4GAOoGwJ5ePSbNYSrT5EttSYzsH7RUqZ34F92Ci1XbXaPsVoDxVzKSOUW7A344LeB+Po+k9j1EsDFL1pOHrvm2XcyVyIDqdL1y6KacaV9QWfZYQKHmmu5bJVe0VpNY7AI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=GJ/1B2u/; arc=none smtp.client-ip=91.218.175.184 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="GJ/1B2u/" X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1760981871; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Opz1DiEiL9POmhUwn0D2PIaPxzczIzD/ebRRhmPcnnc=; b=GJ/1B2u/zGoC19ipzC/6ssZhRiv0uhPjUysylD0DVlLKnlGaoEM1QWsgPXZrzgKpFf8etH ApoBrctSr4BhS/zfZRirerQ+Z9vkWHei/KH3rJ6PPwVoNxrZnZKQ9W7ZPxCLPUFbPb06fe kT7SE3+F698IK6ZxuumoKYgHiLf0pp8= From: Wen Yang To: Greg Kroah-Hartman , Jon Hunter Cc: stable@vger.kernel.org, linux-kernel@vger.kernel.org, K Prateek Nayak , Yicong Yang , Sudeep Holla , Wen Yang Subject: [PATCH 6.1 09/10] drivers: base: cacheinfo: Update cpu_map_populated during CPU Hotplug Date: Tue, 21 Oct 2025 01:36:23 +0800 Message-Id: <20251020173624.20228-10-wen.yang@linux.dev> In-Reply-To: <20251020173624.20228-1-wen.yang@linux.dev> References: <20251020173624.20228-1-wen.yang@linux.dev> 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-Migadu-Flow: FLOW_OUT Content-Type: text/plain; charset="utf-8" From: K Prateek Nayak [ Upstream commit c26fabe73330d983c7ce822c6b6ec0879b4da61f ] Until commit 5c2712387d48 ("cacheinfo: Fix LLC is not exported through sysfs"), cacheinfo called populate_cache_leaves() for CPU coming online which let the arch specific functions handle (at least on x86) populating the shared_cpu_map. However, with the changes in the aforementioned commit, populate_cache_leaves() is not called when a CPU comes online as a result of hotplug since last_level_cache_is_valid() returns true as the cacheinfo data is not discarded. The CPU coming online is not present in shared_cpu_map, however, it will not be added since the cpu_cacheinfo->cpu_map_populated flag is set (it is set in populate_cache_leaves() when cacheinfo is first populated for x86) This can lead to inconsistencies in the shared_cpu_map when an offlined CPU comes online again. Example below depicts the inconsistency in the shared_cpu_list in cacheinfo when CPU8 is offlined and onlined again on a 3rd Generation EPYC processor: # for i in /sys/devices/system/cpu/cpu8/cache/index*/shared_cpu_list; do = echo -n "$i: "; cat $i; done /sys/devices/system/cpu/cpu8/cache/index0/shared_cpu_list: 8,136 /sys/devices/system/cpu/cpu8/cache/index1/shared_cpu_list: 8,136 /sys/devices/system/cpu/cpu8/cache/index2/shared_cpu_list: 8,136 /sys/devices/system/cpu/cpu8/cache/index3/shared_cpu_list: 8-15,136-143 # echo 0 > /sys/devices/system/cpu/cpu8/online # echo 1 > /sys/devices/system/cpu/cpu8/online # for i in /sys/devices/system/cpu/cpu8/cache/index*/shared_cpu_list; do = echo -n "$i: "; cat $i; done /sys/devices/system/cpu/cpu8/cache/index0/shared_cpu_list: 8 /sys/devices/system/cpu/cpu8/cache/index1/shared_cpu_list: 8 /sys/devices/system/cpu/cpu8/cache/index2/shared_cpu_list: 8 /sys/devices/system/cpu/cpu8/cache/index3/shared_cpu_list: 8 # cat /sys/devices/system/cpu/cpu136/cache/index0/shared_cpu_list 136 # cat /sys/devices/system/cpu/cpu136/cache/index3/shared_cpu_list 9-15,136-143 Clear the flag when the CPU is removed from shared_cpu_map when cache_shared_cpu_map_remove() is called during CPU hotplug. This will allow cache_shared_cpu_map_setup() to add the CPU coming back online in the shared_cpu_map. Set the flag again when the shared_cpu_map is setup. Following are results of performing the same test as described above with the changes: # for i in /sys/devices/system/cpu/cpu8/cache/index*/shared_cpu_list; do = echo -n "$i: "; cat $i; done /sys/devices/system/cpu/cpu8/cache/index0/shared_cpu_list: 8,136 /sys/devices/system/cpu/cpu8/cache/index1/shared_cpu_list: 8,136 /sys/devices/system/cpu/cpu8/cache/index2/shared_cpu_list: 8,136 /sys/devices/system/cpu/cpu8/cache/index3/shared_cpu_list: 8-15,136-143 # echo 0 > /sys/devices/system/cpu/cpu8/online # echo 1 > /sys/devices/system/cpu/cpu8/online # for i in /sys/devices/system/cpu/cpu8/cache/index*/shared_cpu_list; do = echo -n "$i: "; cat $i; done /sys/devices/system/cpu/cpu8/cache/index0/shared_cpu_list: 8,136 /sys/devices/system/cpu/cpu8/cache/index1/shared_cpu_list: 8,136 /sys/devices/system/cpu/cpu8/cache/index2/shared_cpu_list: 8,136 /sys/devices/system/cpu/cpu8/cache/index3/shared_cpu_list: 8-15,136-143 # cat /sys/devices/system/cpu/cpu136/cache/index0/shared_cpu_list 8,136 # cat /sys/devices/system/cpu/cpu136/cache/index3/shared_cpu_list 8-15,136-143 Fixes: 5c2712387d48 ("cacheinfo: Fix LLC is not exported through sysfs") Signed-off-by: K Prateek Nayak Reviewed-by: Yicong Yang Reviewed-by: Sudeep Holla Link: https://lore.kernel.org/r/20230508084115.1157-3-kprateek.nayak@amd.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Wen Yang --- drivers/base/cacheinfo.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/base/cacheinfo.c b/drivers/base/cacheinfo.c index 60ecf7cc0250..9e11d42b0d64 100644 --- a/drivers/base/cacheinfo.c +++ b/drivers/base/cacheinfo.c @@ -365,11 +365,14 @@ static int cache_shared_cpu_map_setup(unsigned int cp= u) coherency_max_size =3D this_leaf->coherency_line_size; } =20 + /* shared_cpu_map is now populated for the cpu */ + this_cpu_ci->cpu_map_populated =3D true; return 0; } =20 static void cache_shared_cpu_map_remove(unsigned int cpu) { + struct cpu_cacheinfo *this_cpu_ci =3D get_cpu_cacheinfo(cpu); struct cacheinfo *this_leaf, *sib_leaf; unsigned int sibling, index, sib_index; =20 @@ -404,6 +407,9 @@ static void cache_shared_cpu_map_remove(unsigned int cp= u) if (of_have_populated_dt()) of_node_put(this_leaf->fw_token); } + + /* cpu is no longer populated in the shared map */ + this_cpu_ci->cpu_map_populated =3D false; } =20 static void free_cache_attributes(unsigned int cpu) --=20 2.25.1