linux-kernel - Re: [PATCH v7 06/16] ACPI: processor: Register deferred CPUs from acpi_processor_get

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: <CAJZ5v0hkQ0zTJ3ND5tWAKEJsfthQ-ve08eZpAHMx+9iVT2QQ4w@mail.gmail.com>
Date: Mon, 22 Apr 2024 21:02:28 +0200
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Jonathan Cameron <Jonathan.Cameron@...wei.com>
Cc: Thomas Gleixner <tglx@...utronix.de>, Peter Zijlstra <peterz@...radead.org>, linux-pm@...r.kernel.org, 
	loongarch@...ts.linux.dev, linux-acpi@...r.kernel.org, 
	linux-arch@...r.kernel.org, linux-kernel@...r.kernel.org, 
	linux-arm-kernel@...ts.infradead.org, kvmarm@...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>, 
	Catalin Marinas <catalin.marinas@....com>, Will Deacon <will@...nel.org>, 
	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 v7 06/16] ACPI: processor: Register deferred CPUs from acpi_processor_get_info()

On Thu, Apr 18, 2024 at 3:57 PM Jonathan Cameron
<Jonathan.Cameron@...wei.com> wrote:
>
> From: James Morse <james.morse@....com>
>
> The arm64 specific arch_register_cpu() call may defer CPU registration
> until the ACPI interpreter is available and the _STA method can
> be evaluated.
>
> If this occurs, then a second attempt is made in
> acpi_processor_get_info(). Note that the arm64 specific call has
> not yet been added so for now this will be called for the original
> hotplug case.
>
> For architectures that do not defer until the ACPI Processor
> driver loads (e.g. x86), for initially present CPUs there will
> already be a CPU device. If present do not try to register again.
>
> Systems can still be booted with 'acpi=off', or not include an
> ACPI description at all as in these cases arch_register_cpu()
> will not have deferred registration when first called.
>
> This moves the CPU register logic back to a subsys_initcall(),
> while the memory nodes will have been registered earlier.
> Note this is where the call was prior to the cleanup series so
> there should be no side effects of moving it back again for this
> specific case.
>
> [PATCH 00/21] Initial cleanups for vCPU HP.
> https://lore.kernel.org/all/ZVyz%2FVe5pPu8AWoA@shell.armlinux.org.uk/
> commit 5b95f94c3b9f ("x86/topology: Switch over to GENERIC_CPU_DEVICES")
>
> Signed-off-by: James Morse <james.morse@....com>
> Reviewed-by: Gavin Shan <gshan@...hat.com>
> Tested-by: Miguel Luis <miguel.luis@...cle.com>
> Tested-by: Vishnu Pajjuri <vishnu@...amperecomputing.com>
> Tested-by: Jianyong Wu <jianyong.wu@....com>
> Signed-off-by: Russell King (Oracle) <rmk+kernel@...linux.org.uk>
> Co-developed-by: Jonathan Cameron <Jonathan.Cameron@...wei.com>
> Signed-off-by: Joanthan Cameron <Jonathan.Cameron@...wei.com>
> ---
> v7: Simplify the logic on whether to hotadd the CPU.
>     This path can only be reached either for coldplug in which
>     case all we care about is has register_cpu() already been
>     called (identifying deferred), or hotplug in which case
>     whether register_cpu() has been called is also sufficient.
>     Checks on _STA related elements or the validity of the ID
>     are no longer necessary here due to similar checks having
>     moved elsewhere in the path.
> v6: Squash the two paths for conventional CPU Hotplug and arm64
>     vCPU HP.
> ---
>  drivers/acpi/acpi_processor.c | 14 +++++++-------
>  1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c
> index 127ae8dcb787..4e65011e706c 100644
> --- a/drivers/acpi/acpi_processor.c
> +++ b/drivers/acpi/acpi_processor.c
> @@ -350,14 +350,14 @@ static int acpi_processor_get_info(struct acpi_device *device)
>         }
>
>         /*
> -        *  Extra Processor objects may be enumerated on MP systems with
> -        *  less than the max # of CPUs. They should be ignored _iff
> -        *  they are physically not present.
> -        *
> -        *  NOTE: Even if the processor has a cpuid, it may not be present
> -        *  because cpuid <-> apicid mapping is persistent now.
> +        *  This code is not called unless we know the CPU is present and
> +        *  enabled. The two paths are:
> +        *  a) Initially present CPUs on architectures that do not defer
> +        *     their arch_register_cpu() calls until this point.
> +        *  b) Hotplugged CPUs (enabled bit in _STA has transitioned from not
> +        *     enabled to enabled)
>          */
> -       if (invalid_logical_cpuid(pr->id) || !cpu_present(pr->id)) {
> +       if (!get_cpu_device(pr->id)) {
>                 ret = acpi_processor_hotadd_init(pr, device);

Yes, this is what I thought it should boil down to, so

Acked-by: Rafael J. Wysocki <rafael.j.wysocki@...el.com>

>
>                 if (ret)
> --
> 2.39.2
>