linux-kernel - Re: [PATCH RFC v4 02/15] ACPI: processor: Register all 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]

Date: Wed, 10 Apr 2024 22:07:12 +0100
From: Jonathan Cameron <Jonathan.Cameron@...wei.com>
To: "Rafael J. Wysocki" <rafael@...nel.org>
CC: "Russell King (Oracle)" <linux@...linux.org.uk>,
	<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>,
	<linux-riscv@...ts.infradead.org>, <kvmarm@...ts.linux.dev>,
	<x86@...nel.org>, <acpica-devel@...ts.linuxfoundation.org>,
	<linux-csky@...r.kernel.org>, <linux-doc@...r.kernel.org>,
	<linux-ia64@...r.kernel.org>, <linux-parisc@...r.kernel.org>, Salil Mehta
	<salil.mehta@...wei.com>, Jean-Philippe Brucker <jean-philippe@...aro.org>,
	<jianyong.wu@....com>, <justin.he@....com>, James Morse
	<james.morse@....com>, Miguel Luis <miguel.luis@...cle.com>
Subject: Re: [PATCH RFC v4 02/15] ACPI: processor: Register all CPUs from
 acpi_processor_get_info()

On Wed, 10 Apr 2024 21:08:06 +0200
"Rafael J. Wysocki" <rafael@...nel.org> wrote:

> On Wed, Apr 10, 2024 at 8:56 PM Russell King (Oracle)
> <linux@...linux.org.uk> wrote:
> >
> > On Wed, Apr 10, 2024 at 02:50:05PM +0100, Jonathan Cameron wrote:  
> > > If we get rid of this catch all, solution would be to move the
> > > !acpi_disabled check into the arm64 version of arch_cpu_register()
> > > because we would only want the delayed registration path to be
> > > used on ACPI cases where the question of CPU availability can't
> > > yet be resolved.  
> >
> > Aren't we then needing two arch_register_cpu() implementations?
> > I'm assuming that you're suggesting that the !acpi_disabled, then
> > do nothing check is moved into arch_register_cpu() - or to put it
> > another way, arch_register_cpu() does nothing if ACPI is enabled.
> >
> > If arch_register_cpu() does nothing if ACPI is enabled, how do
> > CPUs get registered (and sysfs files get created to control them)
> > on ACPI systems? ACPI wouldn't be able to call arch_register_cpu(),
> > so I suspect you'll need an ACPI-specific version of this function.  
> 
> arch_register_cpu() will do what it does, but it will check (upfront)
> if ACPI is enabled and if so, if the ACPI Namespace is available.  In
> the case when ACPI is enabled and the ACPI Namespace is not ready, it
> will return -EPROBE_DEFER (say).

Exactly.  I oversimplified and wasn't clear enough.
The check is there in the arch_register_cpu() and is one of the ways
that function can decide to actually register the cpu but not the only one.

I think we may later want to consider breaking it into 2 arch calls
(check if ready to register + register) to reduce code duplication
in with the hotplug path where there is a little extra to do
inbetween.

Hopefully that can wait though.

Jonathan