On 2 February 2015 at 08:50, ethan zhao <ethan.zhao@xxxxxxxxxx> wrote:No, there is no cpufreq_driver_lock acquired between
This seems couldn't prevent all the 'bad thing' from happening, E.G.We take cpufreq_driver_lock() here, and so this will
Thread A: Workqueue: kacpi_notify
acpi_processor_notify()
acpi_processor_ppc_has_changed()
cpufreq_update_policy()
cpufreq_cpu_get()
block thread B.
The problem is you are using a rwsem inside policy structure to protect itsbeginning the deference of policy Thread B:I couldn't understand your problem completely. Apart from giving a detailed
... ... __cpufreq_remove_dev_finish()
cpufreq_policy_free(policy);
Perhaps move policy->rwsem out side the policy structure is a way to avoid
it completely.
and you could stopping the PPC thread stepping forward as my patch as
temporary workaround.
look of what's going on both threads, always specify where the BUG actually
is..