linux-kernel - Re: [RFC PATCH 11/19] cpufreq: assert policy->rwsem is held in __cpufreq

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:	Tue, 02 Feb 2016 20:04:38 -0800
From:	Saravana Kannan <skannan@...eaurora.org>
To:	Viresh Kumar <viresh.kumar@...aro.org>
CC:	"Rafael J. Wysocki" <rafael@...nel.org>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Juri Lelli <juri.lelli@....com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Michael Turquette <mturquette@...libre.com>,
	Steve Muckle <steve.muckle@...aro.org>,
	Vincent Guittot <vincent.guittot@...aro.org>,
	Morten Rasmussen <morten.rasmussen@....com>,
	dietmar.eggemann@....com
Subject: Re: [RFC PATCH 11/19] cpufreq: assert policy->rwsem is held in __cpufreq_governor

On 02/02/2016 06:13 PM, Viresh Kumar wrote:
> On 02-02-16, 13:37, Saravana Kannan wrote:
>> On 02/01/2016 10:34 PM, Viresh Kumar wrote:
>>> What will that solve? It will stay exactly same then as well, as we
>>> would be adding/removing these attributes from within the same
>>> policy->rwsem ..
>>
>> The problem isn't that you are holding the policy rwsem. The problem is that
>> we are trying to grab the same locks in different order. This is trying to
>> fix that.
>
> That's exactly what I was trying to say, sorry for not being very
> clear.
>
> Even if you would move the sysfs file creation thing into the cpufreq
> core, instead of governor, we will have locks this way:
>
> CPU0                            CPU1
> (sysfs read)                    (sysfs dir remove)
> s_active lock                   policy->rwsem
> policy->rwsem
>                                  s_active lock (hang)
>
>
> And so I said, nothing will change.
>

What's the s_active lock in CPU1 coming from? The only reason it's there 
today is because of the sysfs dir remove. If you move it before the 
policy->rwsem, you won't have it after the policy->rwsem too. So, I 
think it will fix the issue.

-Saravana

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project