From: Catalin Marinas <catalin.marinas@arm.com>
To: Pengjie Zhang <zhangpengjie2@huawei.com>
Cc: will@kernel.org, maz@kernel.org, timothy.hayes@arm.com,
lpieralisi@kernel.org, mrigendra.chaubey@gmail.com,
arnd@arndb.de, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, zhanjie9@hisilicon.com,
zhenglifeng1@huawei.com, lihuisong@huawei.com,
yubowen8@huawei.com, linhongye@h-partners.com,
linuxarm@huawei.com, wangzhi12@huawei.com
Subject: Re: [PATCH v2] arm64: smp: Do not mark secondary CPUs possible under nosmp
Date: Mon, 27 Apr 2026 14:20:41 +0100 [thread overview]
Message-ID: <ae9iqdt_qdJRjVZs@arm.com> (raw)
In-Reply-To: <20260423134654.4178271-1-zhangpengjie2@huawei.com>
On Thu, Apr 23, 2026 at 09:46:54PM +0800, Pengjie Zhang wrote:
> Under nosmp (maxcpus=0), arm64 never brings up secondary CPUs.
>
> However, arm64 still enumerates firmware-described CPUs during SMP
> initialization, which can leave secondary CPUs visible to
> for_each_possible_cpu() users even though they never reach the
> bringup path in this configuration.
>
> This is not just a cosmetic mask mismatch: code iterating over
> possible CPUs may observe secondary CPU per-CPU state that is never
> fully initialized under nosmp.
I'm fine with the patch in principle but I fail to see why it is not
mostly cosmetic. If we have possible & !present CPUs (there's another
thread around cpuhp_smt_enable() to allow this combination on arm64),
get_cpu_device() would return NULL and the core code is supposed to
handle this. What other per-CPU state should be initialised for a
possible CPU but it is not without this patch?
--
Catalin
next prev parent reply other threads:[~2026-04-27 13:21 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-23 13:46 [PATCH v2] arm64: smp: Do not mark secondary CPUs possible under nosmp Pengjie Zhang
2026-04-27 13:20 ` Catalin Marinas [this message]
2026-04-30 9:34 ` zhangpengjie (A)
2026-04-30 9:54 ` zhangpengjie (A)
2026-05-01 14:16 ` Catalin Marinas
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=ae9iqdt_qdJRjVZs@arm.com \
--to=catalin.marinas@arm.com \
--cc=arnd@arndb.de \
--cc=lihuisong@huawei.com \
--cc=linhongye@h-partners.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=lpieralisi@kernel.org \
--cc=maz@kernel.org \
--cc=mrigendra.chaubey@gmail.com \
--cc=timothy.hayes@arm.com \
--cc=wangzhi12@huawei.com \
--cc=will@kernel.org \
--cc=yubowen8@huawei.com \
--cc=zhangpengjie2@huawei.com \
--cc=zhanjie9@hisilicon.com \
--cc=zhenglifeng1@huawei.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.