3.18: lockdep problems in cpufreq
Russell King - ARM Linux
linux at arm.linux.org.uk
Mon Dec 15 09:43:36 PST 2014
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.
More information about the linux-arm-kernel
mailing list