From: venkatesh.pallipadi-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org
To: Dave Jones <davej-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
cpufreq-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
kernel-testers-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Ingo Molnar <mingo-X9Un+BFzKDI@public.gmane.org>,
"Rafael J. Wysocki" <rjw-KKrjLPT3xs0@public.gmane.org>,
Dave Young
<hidave.darkstar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Pekka Enberg <penberg-bbCR+/B0CizivPeTLB3BmA@public.gmane.org>,
Mathieu Desnoyers
<mathieu.desnoyers-scC8bbJcJLCw5LPnMra/2Q@public.gmane.org>,
Thomas Renninger <trenn-l3A5Bk7waGM@public.gmane.org>,
Venkatesh Pallipadi
<venkatesh.pallipadi-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Subject: [patch 2/3] cpufreq: Define dbs_mutex purpose and cleanup its usage
Date: Thu, 25 Jun 2009 11:33:56 -0700 [thread overview]
Message-ID: <20090625183601.493904000@intel.com> (raw)
In-Reply-To: 20090625183354.491259000@intel.com
[-- 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
--
WARNING: multiple messages have this Message-ID (diff)
From: venkatesh.pallipadi@intel.com
To: "Dave Jones" <davej@redhat.com>
Cc: linux-kernel@vger.kernel.org, cpufreq@vger.kernel.org,
kernel-testers@vger.kernel.org, "Ingo Molnar" <mingo@elte.hu>,
"Rafael J. Wysocki" <rjw@sisk.pl>,
"Dave Young" <hidave.darkstar@gmail.com>,
"Pekka Enberg" <penberg@cs.helsinki.fi>,
"Mathieu Desnoyers" <mathieu.desnoyers@polymtl.ca>,
"Thomas Renninger" <trenn@suse.de>,
"Venkatesh Pallipadi" <venkatesh.pallipadi@intel.com>
Subject: [patch 2/3] cpufreq: Define dbs_mutex purpose and cleanup its usage
Date: Thu, 25 Jun 2009 11:33:56 -0700 [thread overview]
Message-ID: <20090625183601.493904000@intel.com> (raw)
In-Reply-To: 20090625183354.491259000@intel.com
[-- Attachment #1: 0002-cpufreq-Define-dbs_mutex-purpose-and-cleanup-its-us.patch --]
[-- Type: text/plain, Size: 4121 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@intel.com>
---
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
--
next prev parent reply other threads:[~2009-06-25 18:33 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-25 18:33 [patch 0/3] Take care of cpufreq lockdep issues venkatesh.pallipadi-ral2JQCrhuEAvxtiuMwx3w
2009-06-25 18:33 ` venkatesh.pallipadi
2009-06-25 18:33 ` [patch 1/3] cpufreq: remove rwsem lock from CPUFREQ_GOV_STOP call (second call site) venkatesh.pallipadi-ral2JQCrhuEAvxtiuMwx3w
2009-06-25 18:33 ` venkatesh.pallipadi
2009-06-25 18:33 ` venkatesh.pallipadi-ral2JQCrhuEAvxtiuMwx3w [this message]
2009-06-25 18:33 ` [patch 2/3] cpufreq: Define dbs_mutex purpose and cleanup its usage venkatesh.pallipadi
[not found] ` <20090625183601.493904000-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2009-06-25 19:46 ` Mathieu Desnoyers
2009-06-25 19:46 ` Mathieu Desnoyers
2009-06-25 20:54 ` Pallipadi, Venkatesh
[not found] ` <1245963285.4534.20542.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2009-06-25 21:32 ` Mathieu Desnoyers
2009-06-25 21:32 ` Mathieu Desnoyers
2009-06-25 18:33 ` [patch 3/3] cpufreq: Define dbs_mutex purpose and cleanup its usage conservative gov venkatesh.pallipadi-ral2JQCrhuEAvxtiuMwx3w
2009-06-25 18:33 ` venkatesh.pallipadi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090625183601.493904000@intel.com \
--to=venkatesh.pallipadi-ral2jqcrhueavxtiumwx3w@public.gmane.org \
--cc=cpufreq-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=davej-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=hidave.darkstar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=kernel-testers-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=mathieu.desnoyers-scC8bbJcJLCw5LPnMra/2Q@public.gmane.org \
--cc=mingo-X9Un+BFzKDI@public.gmane.org \
--cc=penberg-bbCR+/B0CizivPeTLB3BmA@public.gmane.org \
--cc=rjw-KKrjLPT3xs0@public.gmane.org \
--cc=trenn-l3A5Bk7waGM@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.