linux-kernel - Re: [PATCH v10 17/19] arm64: Kconfig: Enable hotplug CPU on arm64 if ACPI

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: <ZoEk2mfQkIhLuh-8@arm.com>
Date: Sun, 30 Jun 2024 10:26:50 +0100
From: Catalin Marinas <catalin.marinas@....com>
To: Gavin Shan <gshan@...hat.com>
Cc: Jonathan Cameron <Jonathan.Cameron@...wei.com>,
	Marc Zyngier <maz@...nel.org>, Will Deacon <will@...nel.org>,
	linux-acpi@...r.kernel.org, linux-arch@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	linux-pm@...r.kernel.org, Mark Rutland <mark.rutland@....com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <peterz@...radead.org>, loongarch@...ts.linux.dev,
	x86@...nel.org, Russell King <linux@...linux.org.uk>,
	"Rafael J . Wysocki" <rafael@...nel.org>,
	Miguel Luis <miguel.luis@...cle.com>,
	James Morse <james.morse@....com>,
	Salil Mehta <salil.mehta@...wei.com>,
	Jean-Philippe Brucker <jean-philippe@...aro.org>,
	Hanjun Guo <guohanjun@...wei.com>, Ingo Molnar <mingo@...hat.com>,
	Borislav Petkov <bp@...en8.de>,
	Dave Hansen <dave.hansen@...ux.intel.com>, linuxarm@...wei.com,
	justin.he@....com, jianyong.wu@....com
Subject: Re: [PATCH v10 17/19] arm64: Kconfig: Enable hotplug CPU on arm64 if
 ACPI_PROCESSOR is enabled.

Hi Gavin,

On Sun, Jun 30, 2024 at 10:39:04AM +1000, Gavin Shan wrote:
> On 5/29/24 11:34 PM, Jonathan Cameron wrote:
> > In order to move arch_register_cpu() to be called via the same path
> > for initially present CPUs described by ACPI and hotplugged CPUs
> > ACPI_HOTPLUG_CPU needs to be enabled.
> > 
> > The protection against invalid IDs in acpi_map_cpu() is needed as
> > at least one production BIOS is in the wild which reports entries
> > in DSDT (with no _STA method, so assumed enabled and present)
> > that don't match MADT.
> > 
> > Tested-by: Miguel Luis <miguel.luis@...cle.com>
> > Reviewed-by: Gavin Shan <gshan@...hat.com>
> > Signed-off-by: Jonathan Cameron <Jonathan.Cameron@...wei.com>
> > ---
> >   arch/arm64/Kconfig       |  1 +
> >   arch/arm64/kernel/acpi.c | 22 ++++++++++++++++++++++
> >   2 files changed, 23 insertions(+)
> > 
> > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> > index 5d91259ee7b5..e8f2ef2312db 100644
> > --- a/arch/arm64/Kconfig
> > +++ b/arch/arm64/Kconfig
> > @@ -5,6 +5,7 @@ config ARM64
> >   	select ACPI_CCA_REQUIRED if ACPI
> >   	select ACPI_GENERIC_GSI if ACPI
> >   	select ACPI_GTDT if ACPI
> > +	select ACPI_HOTPLUG_CPU if ACPI_PROCESSOR
> 
> ACPI_HOTPLUG_CPU depends on (ACPI_PROCESSOR && HOTPLUG_CPU). It needs to be:
> 
> 	select ACPI_HOTPLUG_CPU if ACPI_PROCESSOR && HOTPLUG_CPU
> 
> Otherwise, we can have compiling error with the following configurations.
> 
> CONFIG_ACPI_PROCESSOR=y
> CONFIG_HOTPLUG_CPU=n
> CONFIG_ACPI_HOTPLUG_CPU=y
> 
> arch/arm64/kernel/smp.c: In function ‘arch_unregister_cpu’:
> arch/arm64/kernel/smp.c:563:9: error: implicit declaration of function ‘unregister_cpu’; did you mean ‘register_cpu’? [-Werror=implicit-function-declaration]
>   563 |         unregister_cpu(c);
>       |         ^~~~~~~~~~~~~~
>       |         register_cpu

Ah, I thought that in addition to the warning for unmet dependencies,
kbuild would also leave the option off. I need to add SUSPEND=n and
HIBERNATE=n to my build scripts.

The fix matches what x86 does, so I'm ok with it.

> Since the series has been queued to Catalin's "for-next/vcpu-hotplug" branch, I
> guess the easiest way would be to fix it in place with Catalin's help.

I wasn't planning to rebase the branch unless there's something major.
Since the doesn't happen with defconfig, it's doesn't affect bisection
that much, so my preference would be for a fix on top of this branch
(and with a Fixes: tag since the branch is stable).

Thanks.

-- 
Catalin