From: Aaron Plattner <aplattner@nvidia.com>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
Viresh Kumar <viresh.kumar@linaro.org>
Cc: Aaron Plattner <aplattner@nvidia.com>,
cpufreq@vger.kernel.org, linux-pm@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: [PATCH] cpufreq: use cpufreq_cpu_get to avoid cpufreq_get race conditions
Date: Tue, 4 Mar 2014 12:42:15 -0800 [thread overview]
Message-ID: <1393965735-15610-1-git-send-email-aplattner@nvidia.com> (raw)
If a module calls cpufreq_get while cpufreq is initializing, it's possible for
it to be called after cpufreq_driver is set but before cpufreq_cpu_data is
written during subsys_interface_register. This happens because cpufreq_get
doesn't take the cpufreq_driver_lock around its use of cpufreq_cpu_data.
Fix this by using cpufreq_cpu_get(cpu) to look up the policy rather than reading
it out of cpufreq_cpu_data directly. cpufreq_cpu_get takes the appropriate
locks to prevent this race from happening.
Since it's possible for policy to be NULL if the caller passes in an invalid CPU
number or calls the function before cpufreq is initialized, delete the
BUG_ON(!policy) and simply return 0. Don't try to return -ENOENT because that's
negative and the function returns an unsigned integer.
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
---
drivers/cpufreq/cpufreq.c | 21 +++++++--------------
1 file changed, 7 insertions(+), 14 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 8d19f7c..158d0b5 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1447,23 +1447,16 @@ static unsigned int __cpufreq_get(unsigned int cpu)
*/
unsigned int cpufreq_get(unsigned int cpu)
{
- struct cpufreq_policy *policy = per_cpu(cpufreq_cpu_data, cpu);
+ struct cpufreq_policy *policy = cpufreq_cpu_get(cpu);
unsigned int ret_freq = 0;
- if (cpufreq_disabled() || !cpufreq_driver)
- return -ENOENT;
-
- BUG_ON(!policy);
-
- if (!down_read_trylock(&cpufreq_rwsem))
- return 0;
-
- down_read(&policy->rwsem);
-
- ret_freq = __cpufreq_get(cpu);
+ if (policy) {
+ down_read(&policy->rwsem);
+ ret_freq = __cpufreq_get(cpu);
+ up_read(&policy->rwsem);
- up_read(&policy->rwsem);
- up_read(&cpufreq_rwsem);
+ cpufreq_cpu_put(policy);
+ }
return ret_freq;
}
--
1.9.0
next reply other threads:[~2014-03-04 20:42 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-04 20:42 Aaron Plattner [this message]
2014-03-06 1:23 ` [PATCH] cpufreq: use cpufreq_cpu_get to avoid cpufreq_get race conditions Rafael J. Wysocki
2014-03-06 1:14 ` Aaron Plattner
2014-03-06 12:30 ` Rafael J. Wysocki
2014-03-10 4:26 ` Viresh Kumar
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=1393965735-15610-1-git-send-email-aplattner@nvidia.com \
--to=aplattner@nvidia.com \
--cc=cpufreq@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=rjw@rjwysocki.net \
--cc=viresh.kumar@linaro.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).