[patch 0/3] Take care of cpufreq lockdep issues

[patch 0/3] Take care of cpufreq lockdep issues

[venkatesh.pallipadi-ral2JQCrhuEAvxtiuMwx3w]

Since recent chanegs to ondemand and conservative governor, there have been
multiple reports of lockdep issues in cpufreq. Patch series takes care of
these problems.

-- 

[patch 1/3] cpufreq: remove rwsem lock from CPUFREQ_GOV_STOP call (second call site)

[venkatesh.pallipadi-ral2JQCrhuEAvxtiuMwx3w]

[-- Attachment #1: 0001-remove-rwsem-lock-from-CPUFREQ_GOV_STOP-call-second.patch --]
[-- Type: text/plain, Size: 2289 bytes --]

From: Mathieu Desnoyers <mathieu.desnoyers-scC8bbJcJLCw5LPnMra/2Q@public.gmane.org>

commit	42a06f2166f2f6f7bf04f32b4e823eacdceafdc9

Missed a call site for CPUFREQ_GOV_STOP to remove the rwlock taken around the
teardown. To make a long story short, the rwlock write-lock causes a circular
dependency with cancel_delayed_work_sync(), because the timer handler takes the
write lock.

Note that all callers to __cpufreq_set_policy are taking the rwsem. All sysfs
callers (writers) hold the write rwsem at the earliest sysfs calling stage.

However, the rwlock write-lock is not needed upon governor stop.

Change :
- Added comment from Venki at lock definition site.

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers-scC8bbJcJLCw5LPnMra/2Q@public.gmane.org>
Signed-off-by: Thomas Renninger <trenn-l3A5Bk7waGM@public.gmane.org>
Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>

---
 drivers/cpufreq/cpufreq.c |   13 ++++++++++++-
 1 files changed, 12 insertions(+), 1 deletions(-)

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 6e2ec0b..728656c 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -61,6 +61,8 @@ static DEFINE_SPINLOCK(cpufreq_driver_lock);
  *   are concerned with are online after they get the lock.
  * - Governor routines that can be called in cpufreq hotplug path should not
  *   take this sem as top level hotplug notifier handler takes this.
+ * - Lock should not be held across
+ *     __cpufreq_governor(data, CPUFREQ_GOV_STOP);
  */
 static DEFINE_PER_CPU(int, policy_cpu);
 static DEFINE_PER_CPU(struct rw_semaphore, cpu_policy_rwsem);
@@ -1697,8 +1699,17 @@ static int __cpufreq_set_policy(struct cpufreq_policy *data,
 			dprintk("governor switch\n");
 
 			/* end old governor */
-			if (data->governor)
+			if (data->governor) {
+				/*
+				 * Need to release the rwsem around governor
+				 * stop due to lock dependency between
+				 * cancel_delayed_work_sync and the read lock
+				 * taken in the delayed work handler.
+				 */
+				unlock_policy_rwsem_write(data->cpu);
 				__cpufreq_governor(data, CPUFREQ_GOV_STOP);
+				lock_policy_rwsem_write(data->cpu);
+			}
 
 			/* start new governor */
 			data->governor = policy->governor;
-- 
1.6.0.6

-- 

[patch 2/3] cpufreq: Define dbs_mutex purpose and cleanup its usage

[venkatesh.pallipadi-ral2JQCrhuEAvxtiuMwx3w]

[-- Attachment #1: 0002-cpufreq-Define-dbs_mutex-purpose-and-cleanup-its-us.patch --]
[-- Type: text/plain, Size: 4150 bytes --]

Commit b14893a62c73af0eca414cfed505b8c09efc613c although it was very
much needed to cleanup ondemand timer cleanly, openup a can of worms
related to locking dependencies in cpufreq.

Patch here defines the need for dbs_mutex and cleans up its usage in
ondemand governor. This also resolves the lockdep warnings reported here

http://lkml.indiana.edu/hypermail/linux/kernel/0906.1/01925.html

Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
---
 drivers/cpufreq/cpufreq_ondemand.c |   37 +++++++++++++++--------------------
 1 files changed, 16 insertions(+), 21 deletions(-)

diff --git a/drivers/cpufreq/cpufreq_ondemand.c b/drivers/cpufreq/cpufreq_ondemand.c
index 1911d17..b2d2106 100644
--- a/drivers/cpufreq/cpufreq_ondemand.c
+++ b/drivers/cpufreq/cpufreq_ondemand.c
@@ -78,15 +78,14 @@ static DEFINE_PER_CPU(struct cpu_dbs_info_s, cpu_dbs_info);
 static unsigned int dbs_enable;	/* number of CPUs using this policy */
 
 /*
- * DEADLOCK ALERT! There is a ordering requirement between cpu_hotplug
- * lock and dbs_mutex. cpu_hotplug lock should always be held before
- * dbs_mutex. If any function that can potentially take cpu_hotplug lock
- * (like __cpufreq_driver_target()) is being called with dbs_mutex taken, then
- * cpu_hotplug lock should be taken before that. Note that cpu_hotplug lock
- * is recursive for the same process. -Venki
- * DEADLOCK ALERT! (2) : do_dbs_timer() must not take the dbs_mutex, because it
- * would deadlock with cancel_delayed_work_sync(), which is needed for proper
- * raceless workqueue teardown.
+ * dbs_mutex protects data in dbs_tuners_ins from concurrent changes on
+ * different CPUs. It also serializes dbs_enable usage in CPUFREQ_GOV_START
+ * and CPUFREQ_GOV_STOP.
+ *
+ * dbs_mutex should be always held after lock_policy_rwsem whenever needed.
+ * do_dbs_timer() must not take the dbs_mutex, because it would deadlock
+ * with cancel_delayed_work_sync(), which is needed for proper raceless
+ * workqueue teardown.
  */
 static DEFINE_MUTEX(dbs_mutex);
 
@@ -240,12 +239,10 @@ static ssize_t store_sampling_rate(struct cpufreq_policy *unused,
 	unsigned int input;
 	int ret;
 	ret = sscanf(buf, "%u", &input);
+	if (ret != 1)
+		return -EINVAL;
 
 	mutex_lock(&dbs_mutex);
-	if (ret != 1) {
-		mutex_unlock(&dbs_mutex);
-		return -EINVAL;
-	}
 	dbs_tuners_ins.sampling_rate = max(input, min_sampling_rate);
 	mutex_unlock(&dbs_mutex);
 
@@ -258,14 +255,12 @@ static ssize_t store_up_threshold(struct cpufreq_policy *unused,
 	unsigned int input;
 	int ret;
 	ret = sscanf(buf, "%u", &input);
-
-	mutex_lock(&dbs_mutex);
 	if (ret != 1 || input > MAX_FREQUENCY_UP_THRESHOLD ||
 			input < MIN_FREQUENCY_UP_THRESHOLD) {
-		mutex_unlock(&dbs_mutex);
 		return -EINVAL;
 	}
 
+	mutex_lock(&dbs_mutex);
 	dbs_tuners_ins.up_threshold = input;
 	mutex_unlock(&dbs_mutex);
 
@@ -324,8 +319,8 @@ static ssize_t store_powersave_bias(struct cpufreq_policy *unused,
 
 	mutex_lock(&dbs_mutex);
 	dbs_tuners_ins.powersave_bias = input;
-	ondemand_powersave_bias_init();
 	mutex_unlock(&dbs_mutex);
+	ondemand_powersave_bias_init();
 
 	return count;
 }
@@ -598,14 +593,16 @@ static int cpufreq_governor_dbs(struct cpufreq_policy *policy,
 				max(min_sampling_rate,
 				    latency * LATENCY_MULTIPLIER);
 		}
+		mutex_unlock(&dbs_mutex);
+
 		dbs_timer_init(this_dbs_info);
 
-		mutex_unlock(&dbs_mutex);
 		break;
 
 	case CPUFREQ_GOV_STOP:
-		mutex_lock(&dbs_mutex);
 		dbs_timer_exit(this_dbs_info);
+
+		mutex_lock(&dbs_mutex);
 		sysfs_remove_group(&policy->kobj, &dbs_attr_group);
 		dbs_enable--;
 		mutex_unlock(&dbs_mutex);
@@ -613,14 +610,12 @@ static int cpufreq_governor_dbs(struct cpufreq_policy *policy,
 		break;
 
 	case CPUFREQ_GOV_LIMITS:
-		mutex_lock(&dbs_mutex);
 		if (policy->max < this_dbs_info->cur_policy->cur)
 			__cpufreq_driver_target(this_dbs_info->cur_policy,
 				policy->max, CPUFREQ_RELATION_H);
 		else if (policy->min > this_dbs_info->cur_policy->cur)
 			__cpufreq_driver_target(this_dbs_info->cur_policy,
 				policy->min, CPUFREQ_RELATION_L);
-		mutex_unlock(&dbs_mutex);
 		break;
 	}
 	return 0;
-- 
1.6.0.6

-- 

[patch 3/3] cpufreq: Define dbs_mutex purpose and cleanup its usage conservative gov

[venkatesh.pallipadi-ral2JQCrhuEAvxtiuMwx3w]

[-- Attachment #1: 0003-cpufreq-Define-dbs_mutex-purpose-and-cleanup-its-us.patch --]
[-- Type: text/plain, Size: 3106 bytes --]

Commit b253d2b2d28ead6fed012feb54694b3d0562839a although it was very
much needed to cleanup ondemand timer cleanly, openup a can of worms
related to locking dependencies in cpufreq.

Patch here defines the need for dbs_mutex and cleans up its usage in
conservative governor. This also resolves the lockdep warnings in
conservative governor which would be similar to one reported here

http://lkml.indiana.edu/hypermail/linux/kernel/0906.1/01925.html

Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
---
 drivers/cpufreq/cpufreq_conservative.c |   26 ++++++++++++--------------
 1 files changed, 12 insertions(+), 14 deletions(-)

diff --git a/drivers/cpufreq/cpufreq_conservative.c b/drivers/cpufreq/cpufreq_conservative.c
index 7fc58af..581d057 100644
--- a/drivers/cpufreq/cpufreq_conservative.c
+++ b/drivers/cpufreq/cpufreq_conservative.c
@@ -70,15 +70,14 @@ static DEFINE_PER_CPU(struct cpu_dbs_info_s, cpu_dbs_info);
 static unsigned int dbs_enable;	/* number of CPUs using this policy */
 
 /*
- * DEADLOCK ALERT! There is a ordering requirement between cpu_hotplug
- * lock and dbs_mutex. cpu_hotplug lock should always be held before
- * dbs_mutex. If any function that can potentially take cpu_hotplug lock
- * (like __cpufreq_driver_target()) is being called with dbs_mutex taken, then
- * cpu_hotplug lock should be taken before that. Note that cpu_hotplug lock
- * is recursive for the same process. -Venki
- * DEADLOCK ALERT! (2) : do_dbs_timer() must not take the dbs_mutex, because it
- * would deadlock with cancel_delayed_work_sync(), which is needed for proper
- * raceless workqueue teardown.
+ * dbs_mutex protects data in dbs_tuners_ins from concurrent changes on
+ * different CPUs. It also serializes dbs_enable usage in CPUFREQ_GOV_START
+ * and CPUFREQ_GOV_STOP.
+ *
+ * dbs_mutex should be always held after lock_policy_rwsem whenever needed.
+ * do_dbs_timer() must not take the dbs_mutex, because it would deadlock
+ * with cancel_delayed_work_sync(), which is needed for proper raceless
+ * workqueue teardown.
  */
 static DEFINE_MUTEX(dbs_mutex);
 
@@ -590,15 +589,16 @@ static int cpufreq_governor_dbs(struct cpufreq_policy *policy,
 					&dbs_cpufreq_notifier_block,
 					CPUFREQ_TRANSITION_NOTIFIER);
 		}
-		dbs_timer_init(this_dbs_info);
-
 		mutex_unlock(&dbs_mutex);
 
+		dbs_timer_init(this_dbs_info);
+
 		break;
 
 	case CPUFREQ_GOV_STOP:
-		mutex_lock(&dbs_mutex);
 		dbs_timer_exit(this_dbs_info);
+
+		mutex_lock(&dbs_mutex);
 		sysfs_remove_group(&policy->kobj, &dbs_attr_group);
 		dbs_enable--;
 
@@ -616,7 +616,6 @@ static int cpufreq_governor_dbs(struct cpufreq_policy *policy,
 		break;
 
 	case CPUFREQ_GOV_LIMITS:
-		mutex_lock(&dbs_mutex);
 		if (policy->max < this_dbs_info->cur_policy->cur)
 			__cpufreq_driver_target(
 					this_dbs_info->cur_policy,
@@ -625,7 +624,6 @@ static int cpufreq_governor_dbs(struct cpufreq_policy *policy,
 			__cpufreq_driver_target(
 					this_dbs_info->cur_policy,
 					policy->min, CPUFREQ_RELATION_L);
-		mutex_unlock(&dbs_mutex);
 
 		break;
 	}
-- 
1.6.0.6

-- 

Re: [patch 2/3] cpufreq: Define dbs_mutex purpose and cleanup its usage

[Mathieu Desnoyers]

* venkatesh.pallipadi-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org (venkatesh.pallipadi-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org) wrote:
> Commit b14893a62c73af0eca414cfed505b8c09efc613c although it was very
> much needed to cleanup ondemand timer cleanly, openup a can of worms
> related to locking dependencies in cpufreq.
> 
> Patch here defines the need for dbs_mutex and cleans up its usage in
> ondemand governor. This also resolves the lockdep warnings reported here
> 
> http://lkml.indiana.edu/hypermail/linux/kernel/0906.1/01925.html
> 
> Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> ---
>  drivers/cpufreq/cpufreq_ondemand.c |   37 +++++++++++++++--------------------
>  1 files changed, 16 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/cpufreq/cpufreq_ondemand.c b/drivers/cpufreq/cpufreq_ondemand.c
> index 1911d17..b2d2106 100644
> --- a/drivers/cpufreq/cpufreq_ondemand.c
> +++ b/drivers/cpufreq/cpufreq_ondemand.c
> @@ -78,15 +78,14 @@ static DEFINE_PER_CPU(struct cpu_dbs_info_s, cpu_dbs_info);
>  static unsigned int dbs_enable;	/* number of CPUs using this policy */
>  
>  /*
> - * DEADLOCK ALERT! There is a ordering requirement between cpu_hotplug
> - * lock and dbs_mutex. cpu_hotplug lock should always be held before
> - * dbs_mutex. If any function that can potentially take cpu_hotplug lock
> - * (like __cpufreq_driver_target()) is being called with dbs_mutex taken, then
> - * cpu_hotplug lock should be taken before that. Note that cpu_hotplug lock
> - * is recursive for the same process. -Venki
> - * DEADLOCK ALERT! (2) : do_dbs_timer() must not take the dbs_mutex, because it
> - * would deadlock with cancel_delayed_work_sync(), which is needed for proper
> - * raceless workqueue teardown.
> + * dbs_mutex protects data in dbs_tuners_ins from concurrent changes on
> + * different CPUs. It also serializes dbs_enable usage in CPUFREQ_GOV_START
> + * and CPUFREQ_GOV_STOP.
> + *
> + * dbs_mutex should be always held after lock_policy_rwsem whenever needed.
> + * do_dbs_timer() must not take the dbs_mutex, because it would deadlock
> + * with cancel_delayed_work_sync(), which is needed for proper raceless
> + * workqueue teardown.
>   */
>  static DEFINE_MUTEX(dbs_mutex);
>  
> @@ -240,12 +239,10 @@ static ssize_t store_sampling_rate(struct cpufreq_policy *unused,
>  	unsigned int input;
>  	int ret;
>  	ret = sscanf(buf, "%u", &input);
> +	if (ret != 1)
> +		return -EINVAL;
>  
>  	mutex_lock(&dbs_mutex);
> -	if (ret != 1) {
> -		mutex_unlock(&dbs_mutex);
> -		return -EINVAL;
> -	}
>  	dbs_tuners_ins.sampling_rate = max(input, min_sampling_rate);
>  	mutex_unlock(&dbs_mutex);
>  
> @@ -258,14 +255,12 @@ static ssize_t store_up_threshold(struct cpufreq_policy *unused,
>  	unsigned int input;
>  	int ret;
>  	ret = sscanf(buf, "%u", &input);
> -
> -	mutex_lock(&dbs_mutex);
>  	if (ret != 1 || input > MAX_FREQUENCY_UP_THRESHOLD ||
>  			input < MIN_FREQUENCY_UP_THRESHOLD) {
> -		mutex_unlock(&dbs_mutex);
>  		return -EINVAL;
>  	}
>  
> +	mutex_lock(&dbs_mutex);
>  	dbs_tuners_ins.up_threshold = input;
>  	mutex_unlock(&dbs_mutex);
>  
> @@ -324,8 +319,8 @@ static ssize_t store_powersave_bias(struct cpufreq_policy *unused,
>  
>  	mutex_lock(&dbs_mutex);
>  	dbs_tuners_ins.powersave_bias = input;
> -	ondemand_powersave_bias_init();
>  	mutex_unlock(&dbs_mutex);
> +	ondemand_powersave_bias_init();
>  
>  	return count;
>  }
> @@ -598,14 +593,16 @@ static int cpufreq_governor_dbs(struct cpufreq_policy *policy,
>  				max(min_sampling_rate,
>  				    latency * LATENCY_MULTIPLIER);
>  		}
> +		mutex_unlock(&dbs_mutex);
> +
>  		dbs_timer_init(this_dbs_info);
>  
> -		mutex_unlock(&dbs_mutex);
>  		break;
>  
>  	case CPUFREQ_GOV_STOP:
> -		mutex_lock(&dbs_mutex);
>  		dbs_timer_exit(this_dbs_info);

Hrm, so.. how do we protect against concurrent :

CPUFREQ_GOV_START/CPUFREQ_GOV_STOP now ?

Mathieu

> +
> +		mutex_lock(&dbs_mutex);
>  		sysfs_remove_group(&policy->kobj, &dbs_attr_group);
>  		dbs_enable--;
>  		mutex_unlock(&dbs_mutex);
> @@ -613,14 +610,12 @@ static int cpufreq_governor_dbs(struct cpufreq_policy *policy,
>  		break;
>  
>  	case CPUFREQ_GOV_LIMITS:
> -		mutex_lock(&dbs_mutex);
>  		if (policy->max < this_dbs_info->cur_policy->cur)
>  			__cpufreq_driver_target(this_dbs_info->cur_policy,
>  				policy->max, CPUFREQ_RELATION_H);
>  		else if (policy->min > this_dbs_info->cur_policy->cur)
>  			__cpufreq_driver_target(this_dbs_info->cur_policy,
>  				policy->min, CPUFREQ_RELATION_L);
> -		mutex_unlock(&dbs_mutex);
>  		break;
>  	}
>  	return 0;
> -- 
> 1.6.0.6
> 
> -- 
> 

-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

Re: [patch 2/3] cpufreq: Define dbs_mutex purpose and cleanup its usage

[Pallipadi, Venkatesh]

On Thu, 2009-06-25 at 12:46 -0700, Mathieu Desnoyers wrote:
> * venkatesh.pallipadi@intel.com (venkatesh.pallipadi@intel.com) wrote:
> > Commit b14893a62c73af0eca414cfed505b8c09efc613c although it was very
> > much needed to cleanup ondemand timer cleanly, openup a can of worms
> > related to locking dependencies in cpufreq.
> > 
> > Patch here defines the need for dbs_mutex and cleans up its usage in
> > ondemand governor. This also resolves the lockdep warnings reported here
> > 
> > http://lkml.indiana.edu/hypermail/linux/kernel/0906.1/01925.html
> > 

> > @@ -598,14 +593,16 @@ static int cpufreq_governor_dbs(struct cpufreq_policy *policy,
> >  				max(min_sampling_rate,
> >  				    latency * LATENCY_MULTIPLIER);
> >  		}
> > +		mutex_unlock(&dbs_mutex);
> > +
> >  		dbs_timer_init(this_dbs_info);
> >  
> > -		mutex_unlock(&dbs_mutex);
> >  		break;
> >  
> >  	case CPUFREQ_GOV_STOP:
> > -		mutex_lock(&dbs_mutex);
> >  		dbs_timer_exit(this_dbs_info);
> 
> Hrm, so.. how do we protect against concurrent :
> 
> CPUFREQ_GOV_START/CPUFREQ_GOV_STOP now ?

concurrent _START _STOP across CPUs does not matter for timer_init and
timer_exit. On same CPU, there cannot be two concurrent _START as upper
level cpufreq will have policy_rwsem in write mode. I cannot think of a
flow where _START and _STOP on same CPU is possible.

However two concurrent _STOP for same CPU is still possible, as we are
releasing the rwsem lock before STOP callback. "Back to drawing board"
time to figure this all out..

Thanks,
Venki

Re: [patch 2/3] cpufreq: Define dbs_mutex purpose and cleanup its usage

[Mathieu Desnoyers]

* Pallipadi, Venkatesh (venkatesh.pallipadi-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org) wrote:
> On Thu, 2009-06-25 at 12:46 -0700, Mathieu Desnoyers wrote:
> > * venkatesh.pallipadi-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org (venkatesh.pallipadi-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org) wrote:
> > > Commit b14893a62c73af0eca414cfed505b8c09efc613c although it was very
> > > much needed to cleanup ondemand timer cleanly, openup a can of worms
> > > related to locking dependencies in cpufreq.
> > > 
> > > Patch here defines the need for dbs_mutex and cleans up its usage in
> > > ondemand governor. This also resolves the lockdep warnings reported here
> > > 
> > > http://lkml.indiana.edu/hypermail/linux/kernel/0906.1/01925.html
> > > 
> 
> > > @@ -598,14 +593,16 @@ static int cpufreq_governor_dbs(struct cpufreq_policy *policy,
> > >  				max(min_sampling_rate,
> > >  				    latency * LATENCY_MULTIPLIER);
> > >  		}
> > > +		mutex_unlock(&dbs_mutex);
> > > +
> > >  		dbs_timer_init(this_dbs_info);
> > >  
> > > -		mutex_unlock(&dbs_mutex);
> > >  		break;
> > >  
> > >  	case CPUFREQ_GOV_STOP:
> > > -		mutex_lock(&dbs_mutex);
> > >  		dbs_timer_exit(this_dbs_info);
> > 
> > Hrm, so.. how do we protect against concurrent :
> > 
> > CPUFREQ_GOV_START/CPUFREQ_GOV_STOP now ?
> 
> concurrent _START _STOP across CPUs does not matter for timer_init and
> timer_exit.

Given those are per-cpu anyway I guess. Hopefully it works OK with CPU
hotplug.

> On same CPU, there cannot be two concurrent _START as upper
> level cpufreq will have policy_rwsem in write mode.

Agreed.

> I cannot think of a
> flow where _START and _STOP on same CPU is possible.
> 

_STOP is not protected by any mutex now. So it could be preempted, and
then a _START executed, and there is your race.

> However two concurrent _STOP for same CPU is still possible, as we are
> releasing the rwsem lock before STOP callback. "Back to drawing board"
> time to figure this all out..

I fear that it is indeed the case. If you can come up with a document
explaining the expected interactions between :

- cpu hotplug
- policy lock
- cpufreq driver lock
- timer lock

that would be awesome. :)

Mathieu

> 
> Thanks,
> Venki
> 

-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68