linux-kernel - Re: [PATCH] cpufreq: acpi: Don't enable boost on policy exit

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: <CAJZ5v0gcf07YykOS9VsQgHwM0DnphBX4yc9dt5cKjNR8G_4mAQ@mail.gmail.com>
Date: Thu, 17 Apr 2025 17:53:08 +0200
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Viresh Kumar <viresh.kumar@...aro.org>
Cc: Nicholas Chin <nic.c3.14@...il.com>, linux-kernel@...r.kernel.org, 
	linux-pm@...r.kernel.org, rafael.j.wysocki@...el.com, rafael@...nel.org, 
	vincent.guittot@...aro.org, zhenglifeng1@...wei.com
Subject: Re: [PATCH] cpufreq: acpi: Don't enable boost on policy exit

On Thu, Apr 17, 2025 at 2:39 PM Rafael J. Wysocki <rafael@...nel.org> wrote:
>
> On Thu, Apr 17, 2025 at 7:09 AM Viresh Kumar <viresh.kumar@...aro.org> wrote:
> >
> > Copying more information from Bugzilla here (Nicholas, it would be
> > faster if you can put all your observations here first, more people
> > are looking at emails than bugzilla).
> >
> > > Nicholas Chin wrote:
> > > I did some more testing and debugging and it seems like when
> > > cpufreq_online() runs after waking the system, policy->boost_enabled
> > > and cpufreq_boost_enabled() are both 0, so the set_boost() at the end
> > > of that function is never run.
> >
> > Right, this is what I wanted to do with the $Subject patch. Don't
> > update boost anymore in suspend/resume
>
> This is going to work for suspend-to-idle, but not necessarily for S3.
>
> BTW, the patch is correct IMV, so I'm not going to drop it, but it
> looks like something more is needed on top of it.

But the changelog isn't because the patch really doesn't address the
issue at hand, which is most likely related to the platform firmware
clearing the "boost disable" bit.

Frankly, I'd rather get back to the state from before commit
2b16c631832d ("cpufreq: ACPI: Remove set_boost in
acpi_cpufreq_cpu_init()") and start over with the knowledge that the
platform firmware may scribble on the MSR before the kernel gets
control back.

On a way back from system suspend the MSR needs to be put back in sync
with the boost settings in the kernel.