All of lore.kernel.org
 help / color / mirror / Atom feed
From: Viresh Kumar <viresh.kumar@linaro.org>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: linaro-kernel@lists.linaro.org, patches@linaro.org,
	cpufreq@vger.kernel.org, linux-pm@vger.kernel.org,
	linux-kernel@vger.kernel.org, robin.randhawa@arm.com,
	Steve.Bannister@arm.com, Liviu.Dudau@arm.com,
	charles.garcia-tobin@arm.com, arvind.chauhan@arm.com,
	dave.martin@arm.com
Subject: Re: [PATCH 13/13] cpufreq: make sure frequency transitions are serialized
Date: Thu, 27 Jun 2013 10:26:27 +0530	[thread overview]
Message-ID: <CAKohpomGNSA4Pyg6Pn2SiawXPe=wMU7hx0Y7phjfNDV8J+JrLw@mail.gmail.com> (raw)
In-Reply-To: <2081161.dnl1xTqcUT@vostro.rjw.lan>

[-- Attachment #1: Type: text/plain, Size: 3701 bytes --]

On 27 June 2013 03:27, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> Well, now, seeing that the locking around this seems to be kind of haphazard,
> I'm wondering what prevents two different threads from doing CPUFREQ_PRECHANGE
> concurrently in such a way that thread A will check transition_ongoing
> and thread B will check transition_ongoing and then both will set it if it
> was 'false' before.  And then one of them will trigger the WARN() in
> CPUFREQ_POSTCHANGE.
>
> Is there any protection in place and if so then how does it work?

cpufreq_notify_transition() is called from driver->target() which is
called from __cpufreq_driver_target(). __cpufreq_driver_target()
is called directly by governors and cpufreq_driver_target() otherwise.

cpufreq_driver_target() implements proper locking and so it is fine.
__cpufreq_driver_target() is called from governors. From governors
it is is serialized in the sense two threads wouldn't call it at the same
time.

And so I thought this will work. But I just found a mistake in my code.
For multi-socket platforms with clock domains for sockets/clusters,
a single instance of transition_ongoing isn't enough and so this must
be embedded in struct cpufreq_policy.

Below patch must get this fixed (Attached).

-------------x---------------------x-----------------

From: Viresh Kumar <viresh.kumar@linaro.org>
Date: Wed, 19 Jun 2013 10:16:55 +0530
Subject: [PATCH] cpufreq: make sure frequency transitions are serialized

Whenever we are changing frequency of a cpu, we are calling PRECHANGE and
POSTCHANGE notifiers. They must be serialized. i.e. PRECHANGE or POSTCHANGE
shouldn't be called twice contiguously.

This can happen due to bugs in users of __cpufreq_driver_target() or actual
cpufreq drivers who are sending these notifiers.

This patch adds some protection against this. Now, we keep track of the last
transaction and see if something went wrong.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
 drivers/cpufreq/cpufreq.c | 14 ++++++++++++++
 include/linux/cpufreq.h   |  1 +
 2 files changed, 15 insertions(+)

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 2d53f47..75715f1 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -264,6 +264,12 @@ void __cpufreq_notify_transition(struct
cpufreq_policy *policy,
 	switch (state) {

 	case CPUFREQ_PRECHANGE:
+		if (WARN(policy->transition_ongoing,
+				"In middle of another frequency transition\n"))
+			return;
+
+		policy->transition_ongoing = true;
+
 		/* detect if the driver reported a value as "old frequency"
 		 * which is not equal to what the cpufreq core thinks is
 		 * "old frequency".
@@ -283,6 +289,12 @@ void __cpufreq_notify_transition(struct
cpufreq_policy *policy,
 		break;

 	case CPUFREQ_POSTCHANGE:
+		if (WARN(!policy->transition_ongoing,
+				"No frequency transition in progress\n"))
+			return;
+
+		policy->transition_ongoing = false;
+
 		adjust_jiffies(CPUFREQ_POSTCHANGE, freqs);
 		pr_debug("FREQ: %lu - CPU: %lu", (unsigned long)freqs->new,
 			(unsigned long)freqs->cpu);
@@ -1458,6 +1470,8 @@ int __cpufreq_driver_target(struct cpufreq_policy *policy,

 	if (cpufreq_disabled())
 		return -ENODEV;
+	if (policy->transition_ongoing)
+		return -EBUSY;

 	/* Make sure that target_freq is within supported range */
 	if (target_freq > policy->max)
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index 037d36a..8c13a45 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -115,6 +115,7 @@ struct cpufreq_policy {

 	struct kobject		kobj;
 	struct completion	kobj_unregister;
+	bool			transition_ongoing; /* Tracks transition status */
 };

 #define CPUFREQ_ADJUST			(0)

[-- Attachment #2: 0001-cpufreq-make-sure-frequency-transitions-are-serializ.patch --]
[-- Type: application/octet-stream, Size: 2591 bytes --]

From f0573570c85b0fd14db1130ee4885a50ed7bdb94 Mon Sep 17 00:00:00 2001
Message-Id: <f0573570c85b0fd14db1130ee4885a50ed7bdb94.1372308892.git.viresh.kumar@linaro.org>
From: Viresh Kumar <viresh.kumar@linaro.org>
Date: Wed, 19 Jun 2013 10:16:55 +0530
Subject: [PATCH] cpufreq: make sure frequency transitions are serialized

Whenever we are changing frequency of a cpu, we are calling PRECHANGE and
POSTCHANGE notifiers. They must be serialized. i.e. PRECHANGE or POSTCHANGE
shouldn't be called twice contiguously.

This can happen due to bugs in users of __cpufreq_driver_target() or actual
cpufreq drivers who are sending these notifiers.

This patch adds some protection against this. Now, we keep track of the last
transaction and see if something went wrong.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
 drivers/cpufreq/cpufreq.c | 14 ++++++++++++++
 include/linux/cpufreq.h   |  1 +
 2 files changed, 15 insertions(+)

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 2d53f47..75715f1 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -264,6 +264,12 @@ void __cpufreq_notify_transition(struct cpufreq_policy *policy,
 	switch (state) {
 
 	case CPUFREQ_PRECHANGE:
+		if (WARN(policy->transition_ongoing,
+				"In middle of another frequency transition\n"))
+			return;
+
+		policy->transition_ongoing = true;
+
 		/* detect if the driver reported a value as "old frequency"
 		 * which is not equal to what the cpufreq core thinks is
 		 * "old frequency".
@@ -283,6 +289,12 @@ void __cpufreq_notify_transition(struct cpufreq_policy *policy,
 		break;
 
 	case CPUFREQ_POSTCHANGE:
+		if (WARN(!policy->transition_ongoing,
+				"No frequency transition in progress\n"))
+			return;
+
+		policy->transition_ongoing = false;
+
 		adjust_jiffies(CPUFREQ_POSTCHANGE, freqs);
 		pr_debug("FREQ: %lu - CPU: %lu", (unsigned long)freqs->new,
 			(unsigned long)freqs->cpu);
@@ -1458,6 +1470,8 @@ int __cpufreq_driver_target(struct cpufreq_policy *policy,
 
 	if (cpufreq_disabled())
 		return -ENODEV;
+	if (policy->transition_ongoing)
+		return -EBUSY;
 
 	/* Make sure that target_freq is within supported range */
 	if (target_freq > policy->max)
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index 037d36a..8c13a45 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -115,6 +115,7 @@ struct cpufreq_policy {
 
 	struct kobject		kobj;
 	struct completion	kobj_unregister;
+	bool			transition_ongoing; /* Tracks transition status */
 };
 
 #define CPUFREQ_ADJUST			(0)
-- 
1.7.12.rc2.18.g61b472e


  reply	other threads:[~2013-06-27  4:56 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-19  8:52 [PATCH 00/13] CPUFreq: Fix {PRE|POST}CHANGE notification sequence Viresh Kumar
2013-06-19  8:52 ` [PATCH 01/13] cpufreq: acpi: call CPUFREQ_POSTCHANGE notfier in error cases Viresh Kumar
2013-06-19  8:52 ` [PATCH 02/13] cpufreq: arm-big-little: " Viresh Kumar
2013-06-19  8:52 ` [PATCH 03/13] cpufreq: davinci: " Viresh Kumar
2013-06-19  8:58   ` Sekhar Nori
2013-06-19  8:58     ` Sekhar Nori
2013-06-19  8:52 ` [PATCH 04/13] cpufreq: dbx500: " Viresh Kumar
2013-06-19 19:42   ` Linus Walleij
2013-06-19  8:52 ` [PATCH 05/13] cpufreq: e_powersave: " Viresh Kumar
2013-06-19 12:22   ` Simon Horman
2013-06-19 14:54     ` Viresh Kumar
2013-06-19 15:08       ` Dave Jones
2013-06-19  8:53 ` [PATCH 06/13] cpufreq: exynos: " Viresh Kumar
2013-06-19  8:53 ` [PATCH 07/13] cpufreq: imx6q: " Viresh Kumar
2013-06-20  2:52   ` Shawn Guo
2013-06-20  2:52     ` Shawn Guo
2013-06-19  8:53 ` [PATCH 08/13] cpufreq: omap: " Viresh Kumar
2013-06-19 14:44   ` Santosh Shilimkar
2013-06-19 14:44     ` Santosh Shilimkar
2013-06-19  8:53 ` [PATCH 09/13] cpufreq: pcc: " Viresh Kumar
2013-06-19  8:53 ` [PATCH 10/13] cpufreq: powernow-k8: " Viresh Kumar
2013-06-19  8:53 ` [PATCH 11/13] cpufreq: s3c64xx: " Viresh Kumar
2013-06-19  8:53 ` [PATCH 12/13] cpufreq: tegra: " Viresh Kumar
2013-06-19 17:11   ` Stephen Warren
2013-06-19  8:53 ` [PATCH 13/13] cpufreq: make sure frequency transitions are serialized Viresh Kumar
2013-06-24 11:43   ` Rafael J. Wysocki
2013-06-24 13:08     ` Viresh Kumar
2013-06-24 13:23       ` Rafael J. Wysocki
2013-06-24 13:16         ` Viresh Kumar
2013-06-24 13:33           ` Rafael J. Wysocki
2013-06-24 13:31             ` Viresh Kumar
2013-06-26 21:57               ` Rafael J. Wysocki
2013-06-27  4:56                 ` Viresh Kumar [this message]
2013-06-27 12:15                   ` Rafael J. Wysocki
2013-06-24 11:58 ` [PATCH 00/13] CPUFreq: Fix {PRE|POST}CHANGE notification sequence Rafael J. Wysocki

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='CAKohpomGNSA4Pyg6Pn2SiawXPe=wMU7hx0Y7phjfNDV8J+JrLw@mail.gmail.com' \
    --to=viresh.kumar@linaro.org \
    --cc=Liviu.Dudau@arm.com \
    --cc=Steve.Bannister@arm.com \
    --cc=arvind.chauhan@arm.com \
    --cc=charles.garcia-tobin@arm.com \
    --cc=cpufreq@vger.kernel.org \
    --cc=dave.martin@arm.com \
    --cc=linaro-kernel@lists.linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=patches@linaro.org \
    --cc=rjw@sisk.pl \
    --cc=robin.randhawa@arm.com \
    /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.