linux-kernel - Re: linux-next: Tree for Apr 9 [cpufreq: NULL pointer deref]

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:	Mon, 22 Apr 2013 01:30:50 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Viresh Kumar <viresh.kumar@...aro.org>
Cc:	Dirk Brandewie <dirk.brandewie@...il.com>, sedat.dilek@...il.com,
	Dirk Brandewie <dirk.j.brandewie@...el.com>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	linux-next@...r.kernel.org, linux-kernel@...r.kernel.org,
	cpufreq@...r.kernel.org, Linux PM list <linux-pm@...r.kernel.org>,
	Lists linaro-kernel <linaro-kernel@...ts.linaro.org>,
	Nathan Zimmer <nzimmer@....com>
Subject: Re: linux-next: Tree for Apr 9 [cpufreq: NULL pointer deref]

On Monday, April 15, 2013 10:52:28 PM Viresh Kumar wrote:
> On 15 April 2013 21:37, Dirk Brandewie <dirk.brandewie@...il.com> wrote:
> > If the intel_pstate driver is being used __cpufreq_governor() should NOT be
> > called intel_pstate does not implement the target() callback.
> >
> > Nathan's commit 5800043b2 changed the fence around the call to
> > __cpufreq_governor() in __cpufreq_remove_dev() here is the relevant hunk.
> 
> No it isn't.
> 
> > +       if (has_target)
> >                 __cpufreq_governor(data, CPUFREQ_GOV_STOP);
> 
> As it has taken care of this limitation.
> 
> BUT some of my earlier patches haven't. :(
> Here is the fix (Sedat please try this and give your tested-by, use the attached
> patch as gmail might break what i am copying in mail)..
> 
> Sorry for being late in fixing this issue, i am still down with Tonsil infection
> and fever.. Today only i got some power to fix it after seeing Dirk's mail.
> 
> Your tested-by may help me to recover quickly :)
> 
> @Rafael: I will probably be down for one more week and so not doing any
> reviews for now... I do check important mails sent directly to me though.
> 
> ------------x----------------------x------------------
> 
> From: Viresh Kumar <viresh.kumar@...aro.org>
> Date: Mon, 15 Apr 2013 22:43:57 +0530
> Subject: [PATCH] cpufreq: Don't call __cpufreq_governor() for drivers without
>  target()
> 
> Some cpufreq drivers implement their own governor and so don't need us to call
> generic governors interface via __cpufreq_governor(). Few recent commits haven't
> obeyed this law well and we saw some regressions.
> 
> This patch tries to fix this issue.
> 
> Signed-off-by: Viresh Kumar <viresh.kumar@...aro.org>

Applied to linux-pm.git/linux-next, although please check the result, because
the patchwork version of the patch wasn't quite applicable and I fixed it up
manually.

Thanks,
Rafael


> ---
>  drivers/cpufreq/cpufreq.c | 18 +++++++++++++-----
>  1 file changed, 13 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 3564947..a6f6595 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -858,13 +858,18 @@ static int cpufreq_add_policy_cpu(unsigned int
> cpu, unsigned int sibling,
>  				  struct device *dev)
>  {
>  	struct cpufreq_policy *policy;
> -	int ret = 0;
> +	int ret = 0, has_target = 0;
>  	unsigned long flags;
> 
>  	policy = cpufreq_cpu_get(sibling);
>  	WARN_ON(!policy);
> 
> -	__cpufreq_governor(policy, CPUFREQ_GOV_STOP);
> +	rcu_read_lock();
> +	has_target = !!rcu_dereference(cpufreq_driver)->target;
> +	rcu_read_unlock();
> +
> +	if (has_target)
> +		__cpufreq_governor(policy, CPUFREQ_GOV_STOP);
> 
>  	lock_policy_rwsem_write(sibling);
> 
> @@ -877,8 +882,10 @@ static int cpufreq_add_policy_cpu(unsigned int
> cpu, unsigned int sibling,
> 
>  	unlock_policy_rwsem_write(sibling);
> 
> -	__cpufreq_governor(policy, CPUFREQ_GOV_START);
> -	__cpufreq_governor(policy, CPUFREQ_GOV_LIMITS);
> +	if (has_target) {
> +		__cpufreq_governor(policy, CPUFREQ_GOV_START);
> +		__cpufreq_governor(policy, CPUFREQ_GOV_LIMITS);
> +	}
> 
>  	ret = sysfs_create_link(&dev->kobj, &policy->kobj, "cpufreq");
>  	if (ret) {
> @@ -1146,7 +1153,8 @@ static int __cpufreq_remove_dev(struct device
> *dev, struct subsys_interface *sif
> 
>  	/* If cpu is last user of policy, free policy */
>  	if (cpus == 1) {
> -		__cpufreq_governor(data, CPUFREQ_GOV_POLICY_EXIT);
> +		if (has_target)
> +			__cpufreq_governor(data, CPUFREQ_GOV_POLICY_EXIT);
> 
>  		lock_policy_rwsem_read(cpu);
>  		kobj = &data->kobj;
-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/