linux-kernel - Re: [PATCH] cpufreq: Use list_is_last() to check last entry of the policy list

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]

Date:	Wed, 27 Jan 2016 16:42:22 +0530
From:	Gautham R Shenoy <ego@...ux.vnet.ibm.com>
To:	Juri Lelli <juri.lelli@....com>
Cc:	Gautham R Shenoy <ego@...ux.vnet.ibm.com>,
	Viresh Kumar <viresh.kumar@...aro.org>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>, linux-pm@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Shilpasri G Bhat <shilpa.bhat@...ux.vnet.ibm.com>
Subject: Re: [PATCH] cpufreq: Use list_is_last() to check last entry of the
 policy list

On Wed, Jan 27, 2016 at 10:10:20AM +0000, Juri Lelli wrote:
> On 27/01/16 11:39, Gautham R Shenoy wrote:
> > On Mon, Jan 25, 2016 at 11:18:24AM +0000, Juri Lelli wrote:
> > > Hi,
> > > 
> > > On 25/01/16 15:20, Viresh Kumar wrote:
> > > > On 25-01-16, 15:16, Gautham R. Shenoy wrote:
> > > > > Currently next_policy() explicitly checks if a policy is the last
> > > > > policy in the cpufreq_policy_list. Use the standard list_is_last
> > > > > primitive instead.
> > > > > 
> > > > > Cc: Viresh Kumar <viresh.kumar@...aro.org>
> > > > > Signed-off-by: Gautham R. Shenoy <ego@...ux.vnet.ibm.com>
> > > > > ---
> > > > >  drivers/cpufreq/cpufreq.c | 6 +++---
> > > > >  1 file changed, 3 insertions(+), 3 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> > > > > index 78b1e2f..b3059a3 100644
> > > > > --- a/drivers/cpufreq/cpufreq.c
> > > > > +++ b/drivers/cpufreq/cpufreq.c
> > > > > @@ -67,11 +67,11 @@ static struct cpufreq_policy *next_policy(struct cpufreq_policy *policy,
> > > > >  {
> > > > >  	lockdep_assert_held(&cpufreq_driver_lock);
> > > 
> > > Which branch is this patch based on?
> > 
> > My bad! This is based on your branch  git://linux-arm.org/linux-jl.git
> > upstream/cpufreq_cleanups. I found this issue while reviewing your
> > cleanup patches.
> > 
> 
> No problem, and thanks for reviewing those! Any feedback? :)

It's a timely patchset! 

Off late on POWER systems we've been observing a lot of jitters due to
the on-demand worker thread periodically interrupting a running task
to monitor (not necessarily change if the task!) frequency. We would
very much like to see the frequency monitoring/change happen from an
the timer-context instead of waking up a separate worker thread,
something similar to CPUFREQ_DRIVER_FAST in sched_governor.  However,
that approach required a careful audit of all the locks that are
currently taken in cpufreq core and this patch set is a good attempt
in this direction.

Barring the issues raised by Viresh with respect to the locking
conventions around CPUFREQ_GOV_POLICY_EXIT, I didn't have any
particular issues with it.


> 
> Best,
> 
> - Juri
> 

--
Thanks and Regards
gautham.