linux-kernel - Re: [PATCH RFC v3 04/21] 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]

Message-ID: <CAJZ5v0gePAsbRecOXDZ+q-Ds+nsoSBq6VU89ikuQoxds7TeQ3g@mail.gmail.com>
Date: Mon, 22 Jan 2024 19:03:19 +0100
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Jonathan Cameron <Jonathan.Cameron@...wei.com>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>, Russell King <rmk+kernel@...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>
Subject: Re: [PATCH RFC v3 04/21] ACPI: processor: Register all CPUs from acpi_processor_get_info()

On Mon, Jan 22, 2024 at 6:44 PM Jonathan Cameron
<Jonathan.Cameron@...wei.com> wrote:
>
> On Mon, 18 Dec 2023 21:30:50 +0100
> "Rafael J. Wysocki" <rafael@...nel.org> wrote:
>
> > On Wed, Dec 13, 2023 at 1:49 PM Russell King <rmk+kernel@...linux.org.uk> wrote:
> > >
> > > From: James Morse <james.morse@....com>
> > >
> > > To allow ACPI to skip the call to arch_register_cpu() when the _STA
> > > value indicates the CPU can't be brought online right now, move the
> > > arch_register_cpu() call into acpi_processor_get_info().
> >
> > This kind of looks backwards to me and has a potential to become
> > super-confusing.
> >
> > I would instead add a way for the generic code to ask the platform
> > firmware whether or not the given CPU is enabled and so it can be
> > registered.
>
> Hi Rafael,
>
> The ACPI interpreter isn't up at this stage so we'd need to pull that
> forwards. I'm not sure if we can pull the interpreter init early enough.

Well, this patch effectively defers the AP registration to the time
when acpi_processor_get_info() runs and the interpreter is up and
running then.

For consistency, it would be better to defer the AP registration in
general to that point.

> Perhaps pushing the registration back in all cases is the way to go?
> Given the acpi interpretter is initialized via subsys_initcall() it would
> need to be after that - I tried pushing cpu_dev_register_generic()
> immediately after acpi_bus_init() and that seems fine.

Sounds promising.

> We can't leave the rest of cpu_dev_init() that late because a bunch
> of other stuff relies on it (CPU freq blows up first as a core_init()
> on my setup).

I see.

> So to make this work we need it to always move the registration later
> than the necessary infrastructure, perhaps to subsys_initcall_sync()
> as is done for missing CPUs (we'd need to combine the two given that
> needs to run after this, or potentially just stop checking for acpi_disabled
> and don't taint the kernel!).  I think this is probably the most consistent
> option on basis it at least moves the registration to the same point
> whatever is going on and can easily use the arch callback you suggest
> to hide away the logic on deciding if a CPU is there or not.

I agree.