linux-kernel - Re: [PATCH v5 03/18] 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: <20240416145917.00004a7b@huawei.com>
Date: Tue, 16 Apr 2024 15:00:01 +0100
From: Jonathan Cameron <Jonathan.Cameron@...wei.com>
To: <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>, <linuxarm@...wei.com>
CC: <justin.he@....com>, <jianyong.wu@....com>
Subject: Re: [PATCH v5 03/18] ACPI: processor: Register deferred CPUs from
 acpi_processor_get_info()

On Fri, 12 Apr 2024 15:37:04 +0100
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 never be successfully
> called.
> 
> 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/
> 
> e.g. 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>
> ---
> v5: Update commit message to make it clear this is moving the
>     init back to where it was until very recently.
> 
>     No longer change the condition in the earlier registration point
>     as that will be handled by the arm64 registration routine
>     deferring until called again here.
> ---
>  drivers/acpi/acpi_processor.c | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 
> diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c
> index 93e029403d05..c78398cdd060 100644
> --- a/drivers/acpi/acpi_processor.c
> +++ b/drivers/acpi/acpi_processor.c
> @@ -317,6 +317,18 @@ static int acpi_processor_get_info(struct acpi_device *device)
>  
>  	c = &per_cpu(cpu_devices, pr->id);
>  	ACPI_COMPANION_SET(&c->dev, device);
> +	/*
> +	 * Register CPUs that are present. get_cpu_device() is used to skip
> +	 * duplicate CPU descriptions from firmware.
> +	 */
> +	if (!invalid_logical_cpuid(pr->id) && cpu_present(pr->id) &&
> +	    !get_cpu_device(pr->id)) {

Just a quick note to call out that this case of 'duplicate' firmware
description needs an updated comment.  Now we are not deferring
registration on x86 this is detecting that arch_register_cpu()
has already been successfully called and we should not do it again.

I've added rather more detailed comments enumerating of the paths we
can take to hit acpi_processor_hotadd_init() in the v6 series
(tests ongoing)

Jonathan


> +		int ret = arch_register_cpu(pr->id);
> +
> +		if (ret)
> +			return ret;
> +	}
> +
>  	/*
>  	 *  Extra Processor objects may be enumerated on MP systems with
>  	 *  less than the max # of CPUs. They should be ignored _iff