[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1415199239-19019-2-git-send-email-prarit@redhat.com>
Date: Wed, 5 Nov 2014 09:53:55 -0500
From: Prarit Bhargava <prarit@...hat.com>
To: linux-kernel@...r.kernel.org
Cc: robert.schoene@...dresden.de, sboyd@...eaurora.org,
Prarit Bhargava <prarit@...hat.com>,
"Rafael J. Wysocki" <rjw@...ysocki.net>,
Viresh Kumar <viresh.kumar@...aro.org>,
linux-pm@...r.kernel.org
Subject: [PATCH 1/5] cpufreq, do not return stale data to userspace
Consider the following case. Two threads are executing on a system.
Thread 1 is reading from /sys/.../cpufreq/<files> and thread 2 is
changing the cpufreq governor through /sys/.../cpufreq/scaling_governor.
Thread 2 acquires the mutexes in the write path, cpufreq_rwsem and
policy->rwsem, while thread 1 waits.
Thread 2 completes the changing of the scaling governor and releases
the the mutexes.
Thread 1 now acquires the mutexes and returns incorrect data as the
governor has changed.
The kernel cannot guarantee the governor from which the data came from, so
the kernel should fail with -EBUSY when the governor is being written.
Changing the down_read(&policy->rwsem) to a trylock fixes this stale data
issue.
Cc: "Rafael J. Wysocki" <rjw@...ysocki.net>
Cc: Viresh Kumar <viresh.kumar@...aro.org>
Cc: linux-pm@...r.kernel.org
Signed-off-by: Prarit Bhargava <prarit@...hat.com>
---
drivers/cpufreq/cpufreq.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 644b54e..3f09ca9 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -765,7 +765,8 @@ static ssize_t show(struct kobject *kobj, struct attribute *attr, char *buf)
if (!down_read_trylock(&cpufreq_rwsem))
return -EINVAL;
- down_read(&policy->rwsem);
+ if (!down_read_trylock(&policy->rwsem))
+ return -EBUSY;
if (fattr->show)
ret = fattr->show(policy, buf);
--
1.7.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists