linux-kernel - Re: SMP boot issue during system resume

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aVu2mEldTlpMK0hh@willie-the-truck>
Date: Mon, 5 Jan 2026 13:03:20 +0000
From: Will Deacon <will@...nel.org>
To: Pavan Kondeti <pavan.kondeti@....qualcomm.com>
Cc: Mark Rutland <mark.rutland@....com>,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	linux-arm-msm@...r.kernel.org
Subject: Re: SMP boot issue during system resume

On Mon, Jan 05, 2026 at 04:24:44PM +0530, Pavan Kondeti wrote:
> On Fri, Jan 02, 2026 at 03:17:25PM +0000, Will Deacon wrote:
> > On Mon, Dec 22, 2025 at 11:30:19AM +0530, Pavan Kondeti wrote:
> > > We are seeing a SMP boot issue during system resume when CPUs are brought 
> > > online via pm_sleep_enable_secondary_cpus()->thaw_secondary_cpus()->_cpu_up() 
> > > on ARM64.
> > > 
> > > The _cpu_up() sets a global variable
> > > 
> > > secondary_data.task = idle;
> > > 
> > > and wait for the secondary CPU to come online. A 5 second timeout is
> > > used here. If at all, the secondary CPU comes online after this timeout,
> > > we expect it to loop in kernel via __secondary_too_slow(). However, this
> > > depends on secondary_data.task value. Since we are bringing all disabled
> > > cores, after timeout, we set this global variable to the next CPU idle
> > > task and the late secondary CPU thinks the value is its idle task and
> > > does not enter __secondary_too_slow().
> > > 
> > > An earlier attempt [1] to fix similar issue incrased the timout to 5
> > > seconds. We could reproduce this issue in Linux guest where vCPU
> > > scheduling latency can be higher under heavy load on the host.
> > > 
> > > I would like to seek your inputs on how we can improve the current
> > > situation. We would like to avoid __secondary_too_slow() spin even when
> > > the CPU comes late. This is probably not a desired behavior for other cases like 
> > > Linux running bare metal or some guests. Having a Kconfig option or
> > > kernel param might help here.
> > 
> > You probably want to use the parallel hotplug machinery (or one of the
> > interim steps) for this, as it avoids the global state entirely. I spoke
> > about it at KVM forum [1] and I have some old hacks at [2]. I can dust
> > those off and post them to the list if you like?
> 
> Thanks Will for pointing to your informative talk. I see that your patch
> depends on PSCIv0.2 extension to CPU_ON (context argument) [1]. I am not
> sure if this suit our immediate needs, but it is good to know that we
> have a plan for parallel vCPU hotplug.
> 
> I am happy to test if you have any other patches that address /
> workaround this problem w/o depending on backend/firmware.

Surely you're not using PSCI v0.1 in 2026?

Will