From: Ali Ahmet Memis <ali@iusegentoo.com>
To: Shuah Khan <skhan@linuxfoundation.org>,
Shuah Khan <shuah@kernel.org>, Thomas Renninger <trenn@suse.com>,
"John B . Wyatt IV" <jwyatt@redhat.com>,
John Kacur <jkacur@redhat.com>
Cc: linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH v3 0/3] cpupower: fix topology array handling
Date: Thu, 6 Aug 2026 17:51:37 +0000 [thread overview]
Message-ID: <20260806175140.270935-1-ali@iusegentoo.com> (raw)
In-Reply-To: <20260803175215.117518-1-ali@iusegentoo.com>
First, a correction. The v2 cover letter said I had no machine where a
topology attribute actually disappears during enumeration. That was wrong,
and it is the answer to your question about a real scenario: an offline CPU
is enough. The topology attribute group is added and removed by a CPU
hotplug callback in drivers/base/topology.c, so while a CPU is offline it
has no topology directory at all and both reads fail. chcpu -d, a write to
cpuN/online, or turning SMT off all get there.
Measured on a 4 CPU machine against its real sysfs, no fake tree this time,
calling get_cpu_topology() and printing what it decided:
all four CPUs online
unpatched cores=4
v3 series cores=4
cpu2 and cpu3 offlined
unpatched cores=3
with both continues removed cores=3
v3 series cores=2
Two online CPUs, one core each, so 3 is the wrong answer and 4 is
unaffected by the series.
> However, did you consider simplifying the logic in these conditionals?
> -- Is this continue necessary here?
No, they are not necessary, and removing them is the right thing. That is
patch 2. Without them the core == -1 check runs for the entries it was
written for and gives them a defined core_cpu_list of "-1", which is what
you meant by the branch being in the wrong place rather than dead.
It does not change the count on its own though, which is the third row
above. The count is seeded before anything is checked:
last_cpu_list = cpu_top->core_info[0].core_cpu_list;
cpu_top->cores = 1;
and "-1" sorts ahead of a real cpu list, so entry 0 after the qsort is a
placeholder and the count starts by counting it. Patch 3 is about that
seed, so the two changes are complementary rather than alternatives.
Patch 1 is unchanged from v2. Patch 2 makes the demonstrable uninitialized
read go away by itself, but calloc() is still what covers the remaining
path, a core_cpus_list read that fails and only warns, and it is the
smaller change for stable.
v2: https://lore.kernel.org/all/20260803175215.117518-1-ali@iusegentoo.com/
Ali Ahmet Memis (3):
cpupower: zero the topology array to avoid uninitialized reads
cpupower: let the core == -1 check handle failed topology reads
cpupower: do not count incomplete topology entries as physical cores
tools/power/cpupower/lib/cpupower.c | 19 +++++++++++--------
1 file changed, 11 insertions(+), 8 deletions(-)
base-commit: 0d839570765118029aa8bf4a95444c6a11aacf85
--
2.55.0
next prev parent reply other threads:[~2026-08-06 17:52 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-03 17:52 [PATCH v2 0/2] cpupower: fix topology array handling Ali Ahmet Memis
2026-08-03 17:52 ` [PATCH v2 1/2] cpupower: zero the topology array to avoid uninitialized reads Ali Ahmet Memis
2026-08-03 17:52 ` [PATCH v2 2/2] cpupower: do not count incomplete topology entries as physical cores Ali Ahmet Memis
2026-08-04 20:45 ` [PATCH v2 0/2] cpupower: fix topology array handling Shuah Khan
2026-08-05 11:43 ` Ali Ahmet Memis
2026-08-05 12:10 ` Ali Ahmet Memis
2026-08-06 15:50 ` Shuah Khan
2026-08-06 17:51 ` Ali Ahmet Memis [this message]
2026-08-06 17:51 ` [PATCH v3 1/3] cpupower: zero the topology array to avoid uninitialized reads Ali Ahmet Memis
2026-08-06 17:51 ` [PATCH v3 2/3] cpupower: let the core == -1 check handle failed topology reads Ali Ahmet Memis
2026-08-06 17:51 ` [PATCH v3 3/3] cpupower: do not count incomplete topology entries as physical cores Ali Ahmet Memis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260806175140.270935-1-ali@iusegentoo.com \
--to=ali@iusegentoo.com \
--cc=jkacur@redhat.com \
--cc=jwyatt@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=shuah@kernel.org \
--cc=skhan@linuxfoundation.org \
--cc=trenn@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox