On Thu, Nov 30, 2006 at 09:58:07AM +0530, Gautham R Shenoy wrote: > > So can we ignore this circular-dep warning as a false positive? > Or is there a way to exploit this circular dependency ? > > At the moment, I cannot think of way to exploit this circular dependency > unless we do something like try destroying the created workqueue when the > cpu is dead, i.e make the cpufreq governors cpu-hotplug-aware. > (eeks! that doesn't look good)
Ok, I see that we are already doing it :(. So we can end up in a deadlock. Here's the culprit callpath: _cpu_down() ! !-> raw_notifier_call_chain(CPU_LOCK_ACQUIRE) ! ! ! !-> workqueue_cpu_mutex(CPU_LOCK_ACQUIRE) [*] ! !-> raw_notifier_call_chain(CPU_DEAD) ! !-> cpufreq_cpu_callback (CPU_DEAD) ! !-> cpufreq_remove_dev ! !-> __cpufreq_governor(data, GOVERNOR_STOP) ! !-> policy->governor->governor() ! !-> cpufreq_governor_dbs(GOVERNOR_STOP) ! !-> destroy_workqueue() [*] [*] indicates function takes workqueue_mutex. So a deadlock! I wasn't able to observe this because I'm running Xeon SMP box on which you cannot offline cpu0. And cpufreq data is created only for cpu0, while all other cpus cpufreq_data just point to cpu0's cpufreq_data. So the mentioned callpath within cpufreq_remove_dev is never reached during the normal cpu offline cycle. However, if there are architectures which allow the first-booted-cpu (or to be precise, the cpu for which cpufreq_data is *actually* created) to be offlined and we are running Ondemand governor during the offline, we will see this deadlock. regards gautham. -- Gautham R Shenoy Linux Technology Center IBM India. "Freedom comes with a price tag of responsibility, which is still a bargain, because Freedom is priceless!" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/