linux-kernel - [PATCH 1/8] cpufreq: Revert commit a66b2e to fix cpufreq regression during suspend/resume

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 12 Jul 2013 03:45:37 +0530
From:	"Srivatsa S. Bhat" <srivatsa.bhat@...ux.vnet.ibm.com>
To:	rjw@...k.pl, viresh.kumar@...aro.org, toralf.foerster@....de,
	robert.jarzmik@...el.com, durgadoss.r@...el.com,
	tianyu.lan@...el.com, lantianyu1986@...il.com,
	dirk.brandewie@...il.com
Cc:	stern@...land.harvard.edu,
	"Srivatsa S. Bhat" <srivatsa.bhat@...ux.vnet.ibm.com>,
	linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: [PATCH 1/8] cpufreq: Revert commit a66b2e to fix cpufreq regression
 during suspend/resume

commit a66b2e (cpufreq: Preserve sysfs files across suspend/resume) has
unfortunately caused several things in the cpufreq subsystem to break subtly
after a suspend/resume cycle.

The intention of that patch was to retain the file permissions of the
cpufreq related sysfs files across suspend/resume. To achieve that, the commit
completely removed the calls to cpufreq_add_dev() and __cpufreq_remove_dev()
during suspend/resume transitions. But the problem is that those functions
do 2 kinds of things:
  1. Low-level initialization/tear-down that are critical to the correct
     functioning of cpufreq-core.
  2. Kobject and sysfs related initialization/teardown.

Ideally we should have reorganized the code to cleanly separate these two
responsibilities, and skipped only the sysfs related parts during
suspend/resume. Since we skipped the entire callbacks instead (which also
included some CPU and cpufreq-specific critical components), cpufreq
subsystem started behaving erratically after suspend/resume.

So revert the commit to fix the regression. We'll revisit and address the
original goal of that commit separately, since it involves quite a bit of
careful code reorganization and appears to be non-trivial.

(While reverting the commit, note that another commit f51e1eb "cpufreq:
Fix cpufreq regression after suspend/resume" already reverted part of the
original set of changes. So revert only the remaining ones).

Cc: stable@...r.kernel.org
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@...ux.vnet.ibm.com>
---

 drivers/cpufreq/cpufreq.c       |    4 +++-
 drivers/cpufreq/cpufreq_stats.c |    6 ++----
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 6a015ad..ccc6eab 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1941,13 +1941,15 @@ static int __cpuinit cpufreq_cpu_callback(struct notifier_block *nfb,
 	if (dev) {
 		switch (action) {
 		case CPU_ONLINE:
+		case CPU_ONLINE_FROZEN:
 			cpufreq_add_dev(dev, NULL);
 			break;
 		case CPU_DOWN_PREPARE:
-		case CPU_UP_CANCELED_FROZEN:
+		case CPU_DOWN_PREPARE_FROZEN:
 			__cpufreq_remove_dev(dev, NULL);
 			break;
 		case CPU_DOWN_FAILED:
+		case CPU_DOWN_FAILED_FROZEN:
 			cpufreq_add_dev(dev, NULL);
 			break;
 		}
diff --git a/drivers/cpufreq/cpufreq_stats.c b/drivers/cpufreq/cpufreq_stats.c
index cd9e817..12225d1 100644
--- a/drivers/cpufreq/cpufreq_stats.c
+++ b/drivers/cpufreq/cpufreq_stats.c
@@ -353,13 +353,11 @@ static int __cpuinit cpufreq_stat_cpu_callback(struct notifier_block *nfb,
 		cpufreq_update_policy(cpu);
 		break;
 	case CPU_DOWN_PREPARE:
+	case CPU_DOWN_PREPARE_FROZEN:
 		cpufreq_stats_free_sysfs(cpu);
 		break;
 	case CPU_DEAD:
-		cpufreq_stats_free_table(cpu);
-		break;
-	case CPU_UP_CANCELED_FROZEN:
-		cpufreq_stats_free_sysfs(cpu);
+	case CPU_DEAD_FROZEN:
 		cpufreq_stats_free_table(cpu);
 		break;
 	}

--
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/