linux-kernel - [RFC v0 5/9] sched: Use freeze_active() instead CPU_*

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,  4 Sep 2015 15:34:58 +0200
From:	Daniel Wagner <daniel.wagner@...-carit.de>
To:	linux-kernel@...r.kernel.org
Cc:	Daniel Wagner <daniel.wagner@...-carit.de>,
	Ingo Molnar <mingo@...hat.com>,
	Peter Zijlstra <peterz@...radead.org>
Subject: [RFC v0 5/9] sched: Use freeze_active() instead CPU_*_FROZEN state information

In order to get rid of all CPU_*_FROZEN states we need to convert all
users first.

cpuset_cpu_active() tracks via num_cpus_frozen if the current CPU is
the last one. So there is no need to track the exact CPU is in
a CPU_*_FROZEN state. Instead we can probe freeze_active() to tell
if supsens or resume is ongoing.

Signed-off-by: Daniel Wagner <daniel.wagner@...-carit.de>
Cc: Ingo Molnar <mingo@...hat.com>
Cc: Peter Zijlstra <peterz@...radead.org>
Cc: linux-kernel@...r.kernel.org
---
 kernel/sched/core.c | 48 +++++++++++++++++++++++++-----------------------
 1 file changed, 25 insertions(+), 23 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 5de2c9e..36b00eb 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -74,6 +74,7 @@
 #include <linux/binfmts.h>
 #include <linux/context_tracking.h>
 #include <linux/compiler.h>
+#include <linux/suspend.h>
 
 #include <asm/switch_to.h>
 #include <asm/tlb.h>
@@ -7128,28 +7129,28 @@ static int cpuset_cpu_active(struct notifier_block *nfb, unsigned long action,
 			     void *hcpu)
 {
 	switch (action) {
-	case CPU_ONLINE_FROZEN:
-	case CPU_DOWN_FAILED_FROZEN:
-
-		/*
-		 * num_cpus_frozen tracks how many CPUs are involved in suspend
-		 * resume sequence. As long as this is not the last online
-		 * operation in the resume sequence, just build a single sched
-		 * domain, ignoring cpusets.
-		 */
-		num_cpus_frozen--;
-		if (likely(num_cpus_frozen)) {
-			partition_sched_domains(1, NULL, NULL);
-			break;
+	case CPU_ONLINE:
+	case CPU_DOWN_FAILED:
+		if (freeze_active()) {
+			/*
+			 * num_cpus_frozen tracks how many CPUs are
+			 * involved in suspend resume sequence. As
+			 * long as this is not the last online
+			 * operation in the resume sequence, just
+			 * build a single sched domain, ignoring
+			 * cpusets.
+			 */
+			num_cpus_frozen--;
+			if (likely(num_cpus_frozen)) {
+				partition_sched_domains(1, NULL, NULL);
+				break;
+			}
 		}
-
 		/*
-		 * This is the last CPU online operation. So fall through and
-		 * restore the original sched domains by considering the
-		 * cpuset configurations.
+		 * This is the last CPU online operation. Restore the
+		 * original sched domains by considering the cpuset
+		 * configurations.
 		 */
-
-	case CPU_ONLINE:
 		cpuset_update_active_cpus(true);
 		break;
 	default:
@@ -7169,6 +7170,11 @@ static int cpuset_cpu_inactive(struct notifier_block *nfb, unsigned long action,
 
 	switch (action) {
 	case CPU_DOWN_PREPARE:
+		if (freeze_active()) {
+			num_cpus_frozen++;
+			partition_sched_domains(1, NULL, NULL);
+			break;
+		}
 		rcu_read_lock_sched();
 		dl_b = dl_bw_of(cpu);
 
@@ -7183,10 +7189,6 @@ static int cpuset_cpu_inactive(struct notifier_block *nfb, unsigned long action,
 			return notifier_from_errno(-EBUSY);
 		cpuset_update_active_cpus(false);
 		break;
-	case CPU_DOWN_PREPARE_FROZEN:
-		num_cpus_frozen++;
-		partition_sched_domains(1, NULL, NULL);
-		break;
 	default:
 		return NOTIFY_DONE;
 	}
-- 
2.4.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/