linux-kernel - Re: [GIT PULL] ACPI fixes for v5.18-rc5

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]

Date:   Thu, 28 Apr 2022 13:04:35 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     "Rafael J. Wysocki" <rafael@...nel.org>
Cc:     ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
        Linux PM <linux-pm@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] ACPI fixes for v5.18-rc5

On Thu, Apr 28, 2022 at 12:50 PM Rafael J. Wysocki <rafael@...nel.org> wrote:
>
> The bug was that if acpi_idle_bm_check() returned 1, it would "fall
> back"  to the same state via safe_state_index.

That's actually quite hard to see in the source code.

Looking closer, the code calls "acpi_idle_enter_bm()" only when
"cx->type == ACPI_STATE_C3", but that is very non-obvious in the
context of that function (other than the comment).

It might be clearer if the function was actually called "enter_c3()"
rather than "enter_bm()". Particularly since it will continue to do
that "c3_cpu_count" stuff even if the actual power state it goes into
_isn't_ C3.

And the the C3 case doesn't seem to take that "demote C2 to C1" rule
into account, so now that code will go into "safe" C2 mode even if
ACPI_FADT_C2_MP_SUPPORTED isn't set.

It's all very confusing.

But whatever. I obviously already pulled the changes.

                Linus