[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160203021359.GL31828@vireshk>
Date: Wed, 3 Feb 2016 07:43:59 +0530
From: Viresh Kumar <viresh.kumar@...aro.org>
To: Saravana Kannan <skannan@...eaurora.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-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.
--
viresh
Powered by blists - more mailing lists