linux-kernel - Re: [PATCH v2 4/7] ACPI: processor: idle: Disable ACPI idle if get power information failed in power notify

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] [day] [month] [year] [list]

Message-ID: <aad95665-fb6a-477a-b419-4ad88c5db7d2@huawei.com>
Date: Wed, 5 Nov 2025 17:06:56 +0800
From: "lihuisong (C)" <lihuisong@...wei.com>
To: "Rafael J. Wysocki" <rafael@...nel.org>
CC: <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


在 2025/11/5 0:19, Rafael J. Wysocki 写道:
> 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.
 From the initialization perspective, I also think this approach is 
appropriate.
>
> 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?
AFAICS, this power notify can be received on each CPU.
It may be appropriate to update cpuidle state of this CPU if ACPI idle 
supports per-cpu idle state.
Now that all CPUs have the same idle state.
I think it is ok to keep here the same as the initialization logic as 
you said above.
>
> I don't see why it is part of this series to be honest.  It is not a cleanup.
Yes, now it's more like a bugfix.
>