On 08-07-19, 10:28, Rafael J. Wysocki wrote: > Pavel has tested the latest version of the patch series AFAICS. > > The locking added by the commit in question to > refresh_frequency_limits() requires an update of > cpufreq_update_policy(), or it will deadlock in there because of the > lock acquired by cpufreq_cpu_get() if I haven't missed anything.
Ah, looks quite straight forward. @Pavel: Can you please try this diff ? -------------------------8<------------------------- diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c index 9f68d0f306b8..4d6043ee7834 100644 --- a/drivers/cpufreq/cpufreq.c +++ b/drivers/cpufreq/cpufreq.c @@ -1109,16 +1109,12 @@ void refresh_frequency_limits(struct cpufreq_policy *policy) { struct cpufreq_policy new_policy; - down_write(&policy->rwsem); - if (!policy_is_inactive(policy)) { new_policy = *policy; pr_debug("updating policy for CPU %u\n", policy->cpu); cpufreq_set_policy(policy, &new_policy); } - - up_write(&policy->rwsem); } EXPORT_SYMBOL(refresh_frequency_limits); @@ -1128,7 +1124,9 @@ static void handle_update(struct work_struct *work) container_of(work, struct cpufreq_policy, update); pr_debug("handle_update for cpu %u called\n", policy->cpu); + down_write(&policy->rwsem); refresh_frequency_limits(policy); + up_write(&policy->rwsem); } -------------------------8<------------------------- Though it makes me wonder why I didn't hit this thing. I was using the cpu_cooling device the other day, which calls cpufreq_update_policy() very frequently on heat-up. And I had a hair dryer blowing over my board to heat it up. Lemme check that again :) @Rafael: You want me to send a new diff patch with Fixes tag this time if this works out fine ? -- viresh