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: <3f081072-4ed1-439f-b4a9-b86728a51b7d@huawei.com>
Date: Fri, 24 Oct 2025 17:27:53 +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 v1 3/9] ACPI: processor: idle: Return failure when get
 lpi_state->arch_flags failed


在 2025/10/23 18:09, Rafael J. Wysocki 写道:
> On Thu, Oct 23, 2025 at 11:59 AM lihuisong (C) <lihuisong@...wei.com> wrote:
>>
>> 在 2025/10/22 3:36, Rafael J. Wysocki 写道:
>>> On Mon, Sep 29, 2025 at 11:38 AM Huisong Li <lihuisong@...wei.com> wrote:
>>>> The architecture specific context loss flags is important for ARM.
>>>> And this flag is used to control the execution of different code
>>>> flows in acpi_processor_ffh_lpi_enter().
>>>>
>>>> So it is better to return failure when get lpi_state->arch_flags
>>>> failed.
>>> A failure means no idle states at all.
>> Actually, I didn't know why driver should continue to do cpu idle
>> scaling if the idle state doesn't meet the developer's expectations.🙂
> There may be a firmware bug in one state description, but it doesn't
> mean that the other states are unusable, does it?
Ack
>
>>> Wouldn't it be better to skip the state with invalid arch flags?
>> This arch flags is important.  And acpi_processor_ffh_lpi_enter will use it.
>> There is no other place to verify its validity. so here do it.
>> This check is just to prevent potential issues in cpuidle scaling later.
> I'm saying to treat this particular state as invalid and skip it
> without rejecting all of the other states that may be valid.

Ok, handle this case the same as illegal entry method in patch 2/9 if it 
is ok to you.


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ