[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160201060943.GH13476@vireshk>
Date: Mon, 1 Feb 2016 11:39:43 +0530
From: Viresh Kumar <viresh.kumar@...aro.org>
To: "Rafael J. Wysocki" <rjw@...ysocki.net>
Cc: Saravana Kannan <skannan@...eaurora.org>,
Juri Lelli <juri.lelli@....com>, linux-kernel@...r.kernel.org,
linux-pm@...r.kernel.org, peterz@...radead.org,
mturquette@...libre.com, steve.muckle@...aro.org,
vincent.guittot@...aro.org, morten.rasmussen@....com,
dietmar.eggemann@....com
Subject: Re: [RFC PATCH 11/19] cpufreq: assert policy->rwsem is held in
__cpufreq_governor
On 30-01-16, 12:49, Rafael J. Wysocki wrote:
> On Friday, January 29, 2016 04:33:39 PM Saravana Kannan wrote:
> > AFAIR, the ABBA issue was between the sysfs lock and the policy lock.
Yeah, to be precise here it is:
CPU0 (sysfs read) CPU1 (exit governor)
sysfs-read set_policy()-> lock policy->rwsem
sysfs-active lock Remove sysfs files
lock policy->rwsem sysfs-active lock
Actual read
> > The fix for that issue should not be dropping the lock around
> > POLICY_EXIT.
>
> Right. Dropping the lock is a mistake (which I overlooked, sadly).
I joined the party at around time of 3.10, and we had this problem and
hacky solution then as well. We tried to get rid of it multiple times,
but sadly failed.
> > The proper fix is to have the governor "export" the
> > attributes it wants to add/remove and have the cpufreq framework do
> > the adding/removing of the attributes from sysfs for the governor.
I failed to understand your solution, sorry. Care to explain this a
bit more?
--
viresh
Powered by blists - more mailing lists