linux-kernel - Re: [PATCH 1/2] cpufreq: unlock correct rwsem while updating policy->cpu

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, 16 Sep 2013 17:27:03 +0100
From:	"Jon Medhurst (Tixy)" <tixy@...aro.org>
To:	Viresh Kumar <viresh.kumar@...aro.org>
Cc:	rjw@...k.pl, linaro-kernel@...ts.linaro.org, patches@...aro.org,
	cpufreq@...r.kernel.org, linux-pm@...r.kernel.org,
	linux-kernel@...r.kernel.org, srivatsa.bhat@...ux.vnet.ibm.com
Subject: Re: [PATCH 1/2] cpufreq: unlock correct rwsem while updating
 policy->cpu

On Mon, 2013-09-16 at 20:40 +0530, Viresh Kumar wrote:
> Current code looks like this:
> 
>         WARN_ON(lock_policy_rwsem_write(cpu));
>         update_policy_cpu(policy, new_cpu);
>         unlock_policy_rwsem_write(cpu);
> 
> {lock|unlock}_policy_rwsem_write(cpu) takes/releases policy->cpu's rwsem.
> Because cpu is changing with the call to update_policy_cpu(), the
> unlock_policy_rwsem_write() will release the incorrect lock.
> 
> The right solution would be to take rwsem lock/unlock for both old and new cpu.

I thought possibly something like that, then wondered if threads could
take the locks in different orders at the same time, leading to
deadlock? So as I wasn't familiar with cpufreq I thought I'd leave it to
the experts to worry about :-)

This patch contains a bug, see inline comment below. Even with that
fixed it still doesn't work for me. I get a lockdep warning (below). I
have verified the cpu and locks are different locks, and it's not a
harmless false positive because I later get the message 'cpufreq:
__cpufreq_remove_dev_prepare: Failed to stop governor'.

=============================================
[ INFO: possible recursive locking detected ]
3.11.0+ #4 Not tainted
---------------------------------------------
swapper/0/1 is trying to acquire lock:
  (&per_cpu(cpu_policy_rwsem, cpu)){+.+...}, at: [<c0293c03>] update_policy_cpu+0x53/0xa4

but task is already holding lock:
  (&per_cpu(cpu_policy_rwsem, cpu)){+.+...}, at: [<c0293bef>] update_policy_cpu+0x3f/0xa4
other info that might help us debug this:
  Possible unsafe locking scenario:
        CPU0
        ----
   lock(&per_cpu(cpu_policy_rwsem, cpu));
   lock(&per_cpu(cpu_policy_rwsem, cpu));

*** DEADLOCK ***

  May be due to missing lock nesting notation
4 locks held by swapper/0/1:
 #0:  (bL_switcher_activation_lock){+.+.+.}, at: [<c0019b03>] bL_switcher_enable+0x17/0x2d8
 #1:  ((bL_activation_notifier).rwsem){.+.+.+}, at: [<c00370bd>] __blocking_notifier_call_chain+0x1d/0x40
 #2:  (subsys mutex#6){+.+.+.}, at: [<c023279d>] subsys_interface_unregister+0x1d/0x68
 #3:  (&per_cpu(cpu_policy_rwsem, cpu)){+.+...}, at: [<c0293bef>] update_policy_cpu+0x3f/0xa4

> This patch fixes this bug by taking both locks directly instead of calling
> lock_policy_rwsem_write().
> 
> Reported-by: Jon Medhurst<tixy@...aro.org>
> Signed-off-by: Viresh Kumar <viresh.kumar@...aro.org>
> ---
> Hi Rafael,
> 
> Probably we can get this patch in for 3.12? The second one can go in 3.13.
> 
> These are compile tested only at my end. Tixy reported these and probably can
> give his tested-by once he is done testing them.
> 
>  drivers/cpufreq/cpufreq.c | 9 +++++++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
If I take mainline code and just change the line above to:
   up_write(&per_cpu(cpu_policy_rwsem, (per_cpu(cpufreq_cpu_data,
cpu))->last_cpu));
then the big_little cpufreq driver works for me.

> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 43c24aa..c18bf7b 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -952,9 +952,16 @@ static void update_policy_cpu(struct cpufreq_policy *policy, unsigned int cpu)
>  	if (cpu == policy->cpu)
>  		return;
>  
> +	/* take direct locks as lock_policy_rwsem_write wouldn't work here */
> +	down_write(&per_cpu(cpu_policy_rwsem, policy->cpu));
> +	down_write(&per_cpu(cpu_policy_rwsem, cpu));
> +
>  	policy->last_cpu = policy->cpu;
>  	policy->cpu = cpu;
>  
> +	up_write(&per_cpu(cpu_policy_rwsem, cpu));
> +	up_write(&per_cpu(cpu_policy_rwsem, policy->cpu));

You've just overwritten policy->cpu with cpu. I tried using
policy->last_cpu to fix that, but it still doesn't work for me (giving
the lockdep warning I mentioned.) If I change the code to just lock the
original policy->cpu lock only, then all is fine.

Also, this locking is now just happening around policy->cpu update,
whereas before this change, it was locked for the whole of
update_policy_cpu, i.e. cpufreq_frequency_table_update_policy_cpu and
the notifier callbacks. Is that change of lock coverage OK?

> +
>  #ifdef CONFIG_CPU_FREQ_TABLE
>  	cpufreq_frequency_table_update_policy_cpu(policy);
>  #endif
> @@ -1203,9 +1210,7 @@ static int __cpufreq_remove_dev_prepare(struct device *dev,
>  
>  		new_cpu = cpufreq_nominate_new_policy_cpu(policy, cpu, frozen);
>  		if (new_cpu >= 0) {
> -			WARN_ON(lock_policy_rwsem_write(cpu));
>  			update_policy_cpu(policy, new_cpu);
> -			unlock_policy_rwsem_write(cpu);
>  
>  			if (!frozen) {
>  				pr_debug("%s: policy Kobject moved to cpu: %d "

-- 
Tixy

--
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/