linux-kernel - Re: [PATCH 3/11] cpufreq: governor: Use common global_dbs

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: <20160204053614.GV3469@vireshk>
Date:	Thu, 4 Feb 2016 11:06:14 +0530
From:	Viresh Kumar <viresh.kumar@...aro.org>
To:	"Rafael J. Wysocki" <rjw@...ysocki.net>
Cc:	Linux PM list <linux-pm@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>,
	Juri Lelli <juri.lelli@....com>,
	Steve Muckle <steve.muckle@...aro.org>,
	Saravana Kannan <skannan@...eaurora.org>
Subject: Re: [PATCH 3/11] cpufreq: governor: Use common global_dbs_data
 pointer

On 04-02-16, 00:22, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
> 
> If the ondemand and conservative governors cannot use per-policy
> tunables (CPUFREQ_HAVE_GOVERNOR_PER_POLICY is not set in the cpufreq
> driver), all policy objects point to the same single dbs_data object.
> Additionally, that object is pointed to by a global pointer hidden in
> the governor's data structures.
> 
> There is no reason for that pointer to be buried in those
> data structures, though, so make it explicitly global.
> 
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@...el.com>

> Index: linux-pm/drivers/cpufreq/cpufreq_governor.c
> ===================================================================
> --- linux-pm.orig/drivers/cpufreq/cpufreq_governor.c
> +++ linux-pm/drivers/cpufreq/cpufreq_governor.c
> @@ -22,6 +22,9 @@
>  
>  #include "cpufreq_governor.h"
>  
> +struct dbs_data *global_dbs_data;
> +EXPORT_SYMBOL_GPL(global_dbs_data);

Oh man, please save me from Rafael's Rant :)

I think, this is simply wrong.

Believe me its very difficult for me to say this to you :). You are
way better than me, and I am sure that I haven't understood cupfreq
after so many years :)

Consider a two policy system, who is stopping us from setting ondemand
for one of them and conservative for the other one ? And so, we will
have two gdbs_data ..

Sorry for the noise, if I am being utterly stupid :(

-- 
viresh