linux-kernel - Re: [PATCH] cpufreq: ondemand: update sampling rate only on right CPUs

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]

Message-ID: <38705460.ie2PzG104T@vostro.rjw.lan>
Date:	Tue, 27 Nov 2012 23:08:27 +0100
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	linux-pm@...r.kernel.org
Cc:	Fabio Baltieri <fabio.baltieri@...aro.org>,
	cpufreq@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] cpufreq: ondemand: update sampling rate only on right CPUs

On Monday, November 26, 2012 07:10:12 PM Fabio Baltieri wrote:
> Fix cpufreq_gov_ondemand to skip CPU where another governor is used.
> 
> The bug present itself as NULL pointer access on the mutex_lock() call,
> an can be reproduced on an SMP machine by setting the default governor
> to anything other than ondemand, setting a single CPU's governor to
> ondemand, then changing the sample rate by writing on:
> 
> > /sys/devices/system/cpu/cpufreq/ondemand/sampling_rate
> 
> Backtrace:
> 
> Nov 26 17:36:54 balto kernel: [  839.585241] BUG: unable to handle kernel NULL pointer dereference at           (null)
> Nov 26 17:36:54 balto kernel: [  839.585311] IP: [<ffffffff8174e082>] __mutex_lock_slowpath+0xb2/0x170
> [snip]
> Nov 26 17:36:54 balto kernel: [  839.587005] Call Trace:
> Nov 26 17:36:54 balto kernel: [  839.587030]  [<ffffffff8174da82>] mutex_lock+0x22/0x40
> Nov 26 17:36:54 balto kernel: [  839.587067]  [<ffffffff81610b8f>] store_sampling_rate+0xbf/0x150
> Nov 26 17:36:54 balto kernel: [  839.587110]  [<ffffffff81031e9c>] ?  __do_page_fault+0x1cc/0x4c0
> Nov 26 17:36:54 balto kernel: [  839.587153]  [<ffffffff813309bf>] kobj_attr_store+0xf/0x20
> Nov 26 17:36:54 balto kernel: [  839.587192]  [<ffffffff811bb62d>] sysfs_write_file+0xcd/0x140
> Nov 26 17:36:54 balto kernel: [  839.587234]  [<ffffffff8114c12c>] vfs_write+0xac/0x180
> Nov 26 17:36:54 balto kernel: [  839.587271]  [<ffffffff8114c472>] sys_write+0x52/0xa0
> Nov 26 17:36:54 balto kernel: [  839.587306]  [<ffffffff810321ce>] ?  do_page_fault+0xe/0x10
> Nov 26 17:36:54 balto kernel: [  839.587345]  [<ffffffff81751202>] system_call_fastpath+0x16/0x1b
> 
> Signed-off-by: Fabio Baltieri <fabio.baltieri@...aro.org>
> ---
> 
> Hi Rafael,
> 
> this is based on a clean linux-pm linux-next branch (i.e. not with my other
> patch-set applied), so expect a context conflict if both are applied.

I have applied this patch to my linux-next branch.

As for the other series, I'm in the process of reviewing it, but I rather
won't include it into my first pull request for v3.8.

Thanks,
Rafael


>  drivers/cpufreq/cpufreq_ondemand.c | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/cpufreq/cpufreq_ondemand.c b/drivers/cpufreq/cpufreq_ondemand.c
> index cca3e9f..7731f7c 100644
> --- a/drivers/cpufreq/cpufreq_ondemand.c
> +++ b/drivers/cpufreq/cpufreq_ondemand.c
> @@ -40,6 +40,10 @@
>  static struct dbs_data od_dbs_data;
>  static DEFINE_PER_CPU(struct od_cpu_dbs_info_s, od_cpu_dbs_info);
>  
> +#ifndef CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND
> +static struct cpufreq_governor cpufreq_gov_ondemand;
> +#endif
> +
>  static struct od_dbs_tuners od_tuners = {
>  	.up_threshold = DEF_FREQUENCY_UP_THRESHOLD,
>  	.sampling_down_factor = DEF_SAMPLING_DOWN_FACTOR,
> @@ -279,6 +283,10 @@ static void update_sampling_rate(unsigned int new_rate)
>  		policy = cpufreq_cpu_get(cpu);
>  		if (!policy)
>  			continue;
> +		if (policy->governor != &cpufreq_gov_ondemand) {
> +			cpufreq_cpu_put(policy);
> +			continue;
> +		}
>  		dbs_info = &per_cpu(od_cpu_dbs_info, policy->cpu);
>  		cpufreq_cpu_put(policy);
>  
> 
-- 
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/