Re: 3.18: lockdep problems in cpufreq

[Russell King - ARM Linux <linux@arm.linux.org.uk>]

On Mon, Dec 15, 2014 at 08:24:05PM +0530, Yadwinder Singh Brar wrote:
> > The answer may well be to have finer grained locking here:
> > 
> > - one lock to protect cpufreq_dev_list, which is only ever taken when
> >   adding or removing entries from it
> > 
> > - a second lock to protect cpufreq_dev_count and the calls to
> >   cpufreq_register_notifier() and cpufreq_unregister_notifier()
> > 
> > and you would /never/ take either of those two locks inside each other.
> > In other words:
> > 
> > 	mutex_lock(&cooling_list_lock);
> > 	list_add(&cpufreq_dev->node, &cpufreq_dev_list);
> > 	mutex_unlock(&cooling_list_lock);
> > 
> > 	mutex_lock(&cooling_cpufreq_lock);
> > 	if (cpufreq_dev_count++ == 0)
> > 		cpufreq_register_notifier(&thermal_cpufreq_notifier_block,
> > 					  CPUFREQ_POLICY_NOTIFIER);
> > 	mutex_unlock(&cooling_cpufreq_lock);
> > 
> > and similar in the cleanup path.  The notifier itself would only ever
> > take the cooling_list_lock.
> > 
> 
> I agree with this approach, if its fine for others also, I can implement
> and post patch.

Yes, please do.

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.