linux-kernel - Re: [PATCH v1 2/6] cpufreq: intel_pstate: Do not update global.turbo

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: Sat, 08 Jun 2024 17:30:50 +0800
From: Xi Ruoyao <xry111@...111.site>
To: srinivas pandruvada <srinivas.pandruvada@...ux.intel.com>, "Rafael J.
 Wysocki" <rafael@...nel.org>
Cc: "Rafael J. Wysocki" <rjw@...ysocki.net>, Linux PM
 <linux-pm@...r.kernel.org>,  LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v1 2/6] cpufreq: intel_pstate: Do not update
 global.turbo_disabled after initialization

On Fri, 2024-06-07 at 08:18 -0700, srinivas pandruvada wrote:
> On Fri, 2024-06-07 at 17:04 +0200, Rafael J. Wysocki wrote:
> > On Wed, Jun 5, 2024 at 2:05 PM srinivas pandruvada
> > <srinivas.pandruvada@...ux.intel.com> wrote:
> > > 
> > > On Wed, 2024-06-05 at 13:21 +0800, Xi Ruoyao wrote:
> > > > On Tue, 2024-06-04 at 09:56 -0700, srinivas pandruvada wrote:
> > > > > > > With such a delay, I am not sure how this even worked
> > > > > > > before.
> > > > 
> > > > It didn't work out of box but it worked after manually writing 0
> > > > to
> > > > no_turbo after 20 seconds, see
> > > > https://bugzilla.kernel.org/show_bug.cgi?id=218702.
> > > 
> > > That make sense. So it never worked out of box. The
> > > store_no_turbo()
> > > has additional read for turbo flag before, which is removed now. I
> > > think adding that back will will restore old behavior.
> > > 
> > > diff --git a/drivers/cpufreq/intel_pstate.c
> > > b/drivers/cpufreq/intel_pstate.c
> > > index 4b986c044741..0d5330e5b96b 100644
> > > --- a/drivers/cpufreq/intel_pstate.c
> > > +++ b/drivers/cpufreq/intel_pstate.c
> > > @@ -1301,6 +1301,8 @@ static ssize_t store_no_turbo(struct kobject
> > > *a,
> > > struct kobj_attribute *b,
> > > 
> > >         no_turbo = !!clamp_t(int, input, 0, 1);
> > > 
> > > +       global.turbo_disabled = turbo_is_disabled();
> > > +
> > >         if (no_turbo == global.no_turbo)
> > >                 goto unlock_driver;
> > > 
> > > 
> > > Need to adjust the mutex around it also.
> > 
> > Anyhow, it can be made work.
> > 
> > global.turbo_disabled can be updated right before it is checked in
> > store_no_turbo(), so if 0 is written to no_turbo (and global.no_turbo
> > is 1), it will succeed if global.turbo_disabled changes from 1 to 0.
> > 
> > Something like the attached (untested) patch.
> 
> Should work.
> 
> Xi,
> Please test so that we can close this issue.

Yes it restores the old behavior for me.

Tested-by: Xi Ruoyao <xry111@...111.site>

-- 
Xi Ruoyao <xry111@...111.site>
School of Aerospace Science and Technology, Xidian University