Messages in this thread | | | Subject | Re: [patch 00/61] ANNOUNCE: lock validator -V1 | From | Arjan van de Ven <> | Date | Tue, 30 May 2006 07:45:47 +0200 |
| |
> I'm feeling a bit overwhelmed by the voluminous output of this checker. > Especially as (directly at least) cpufreq doesn't touch vma's, or mmap's.
the reporter doesn't have CONFIG_KALLSYMS_ALL enabled which gives sometimes misleading backtraces (should lockdep just enable KALLSYMS_ALL to get more useful bugreports?)
the problem is this, there are 2 scenarios in this bug:
One --- store_scaling_governor takes policy->lock and then calls __cpufreq_set_policy __cpufreq_set_policy calls __cpufreq_governor __cpufreq_governor calls __cpufreq_driver_target via cpufreq_governor_performance __cpufreq_driver_target calls lock_cpu_hotplug() (which takes the hotplug lock)
Two --- cpufreq_stats_init lock_cpu_hotplug() and then calls cpufreq_stat_cpu_callback cpufreq_stat_cpu_callback calls cpufreq_update_policy cpufreq_update_policy takes the policy->lock
so this looks like a real honest AB-BA deadlock to me...
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |