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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJZ5v0ii=ZJeCisXx3EOOMfqe8rRn=FvKBDsNuBucxvM0WXvgg@mail.gmail.com>
Date: Tue, 4 Nov 2025 17:19:44 +0100
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: "lihuisong (C)" <lihuisong@...wei.com>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>, lenb@...nel.org, linux-acpi@...r.kernel.org, 
	linux-kernel@...r.kernel.org, Sudeep.Holla@....com, linuxarm@...wei.com, 
	jonathan.cameron@...wei.com, zhanjie9@...ilicon.com, zhenglifeng1@...wei.com, 
	yubowen8@...wei.com
Subject: Re: [PATCH v2 4/7] ACPI: processor: idle: Disable ACPI idle if get
 power information failed in power notify

On Tue, Nov 4, 2025 at 10:54 AM lihuisong (C) <lihuisong@...wei.com> wrote:
>
>
> 在 2025/11/4 2:09, Rafael J. Wysocki 写道:
> > On Mon, Nov 3, 2025 at 9:42 AM Huisong Li <lihuisong@...wei.com> wrote:
> >> The old states may not be usable any more if get power information
> >> failed in power notify. The ACPI idle should be disabled entirely.
> > How does it actually disable anything?  It only changes the
> > acpi_processor_power_state_has_changed() return value AFAICS, but that
> > return value isn't checked.
> The acpi_processor_power_state_has_changed() will disable all cpuidle
> device first.
> AFAICS, the disabled cpuidle_device would not do cpuidle, please see
> cpuidle_not_available() and cpuidle_idle_call().
> It's enough for this?

Well, not really.

acpi_processor_register_idle_driver() has been changed to call
acpi_processor_get_power_info() for each CPU before registering the
idle driver and if that is successful, it will set
flags.power_setup_done for the given processor and call
acpi_processor_setup_cpuidle_states().  That processor need not be
CPU0.

However, the code updated by the $subject patch calls
acpi_processor_get_power_info() for CPU0 and the patch would make it
skip re-enabling cpuidle for all CPUs if it failed.

It essentially needs to do what is done in
acpi_processor_register_idle_driver(): find a CPU for which
acpi_processor_get_power_info() does not fail, then call
acpi_processor_setup_cpuidle_states() and re-enable cpuidle for all
CPUs unless acpi_processor_get_power_info() fails for all of them.

But there is still a question of whether or not this addresses any
breakage seen in the field.  If not, maybe it's better to leave this
code as is for the time being?

I don't see why it is part of this series to be honest.  It is not a cleanup.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ