linux-kernel - [PATCH] sched: for 0day robot: don't abuse 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>] [day] [month] [year] [list]

Message-ID: <20151015151248.GA22118@redhat.com>
Date:	Thu, 15 Oct 2015 17:12:49 +0200
From:	Oleg Nesterov <oleg@...hat.com>
To:	Peter Zijlstra <peterz@...radead.org>,
	Fengguang Wu <fengguang.wu@...el.com>
Cc:	Heiko Carstens <heiko.carstens@...ibm.com>,
	Tejun Heo <tj@...nel.org>, Ingo Molnar <mingo@...nel.org>,
	Rik van Riel <riel@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Vitaly Kuznetsov <vkuznets@...hat.com>,
	linux-kernel@...r.kernel.org
Subject: [PATCH] sched: for 0day robot: don't abuse cpu_active()

On 10/14, Peter Zijlstra wrote:
>
> On Wed, Oct 14, 2015 at 10:05:16PM +0200, Oleg Nesterov wrote:
> > Yes, because that damn cpu_active() check doesn't look strictly necessary ;)
> > Or I misunderstood.
>
> How about we sit down and have a hard look after Thomas is done
> revamping hotplug? I don't want to go pour over hotplug code that is
> guaranteed to change.

OK, understand.

But I have an idea ;) It seems that the Fengguang's robot is more
clever than me. Let me change the subject and add s-o-b to seduce
it to test this change.

Once again, I agree, lets forget this change for now. But if I missed
something and we can't do this, perhaps the robot will explain why.

Signed-off-by: Oleg Nesterov <oleg@...hat.com>
---
 arch/powerpc/kernel/smp.c |    2 +-
 arch/s390/kernel/smp.c    |    2 +-
 kernel/sched/core.c       |   12 ------------
 3 files changed, 2 insertions(+), 14 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 5fe9086..a2ef0cf 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -1557,8 +1557,6 @@ static int select_fallback_rq(int cpu, s
 		for_each_cpu(dest_cpu, nodemask) {
 			if (!cpu_online(dest_cpu))
 				continue;
-			if (!cpu_active(dest_cpu))
-				continue;
 			if (cpumask_test_cpu(dest_cpu, tsk_cpus_allowed(p)))
 				return dest_cpu;
 		}
@@ -1569,8 +1567,6 @@ static int select_fallback_rq(int cpu, s
 		for_each_cpu(dest_cpu, tsk_cpus_allowed(p)) {
 			if (!cpu_online(dest_cpu))
 				continue;
-			if (!cpu_active(dest_cpu))
-				continue;
 			goto out;
 		}
 
@@ -5519,14 +5515,6 @@ static int sched_cpu_active(struct notif
 	case CPU_STARTING:
 		set_cpu_rq_start_time();
 		return NOTIFY_OK;
-	case CPU_ONLINE:
-		/*
-		 * At this point a starting CPU has marked itself as online via
-		 * set_cpu_online(). But it might not yet have marked itself
-		 * as active, which is essential from here on.
-		 *
-		 * Thus, fall-through and help the starting CPU along.
-		 */
 	case CPU_DOWN_FAILED:
 		set_cpu_active((long)hcpu, true);
 		return NOTIFY_OK;
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index ec9ec20..d57dad0 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -542,7 +542,7 @@ int __cpu_up(unsigned int cpu, struct task_struct *tidle)
 		smp_ops->give_timebase();
 
 	/* Wait until cpu puts itself in the online & active maps */
-	while (!cpu_online(cpu) || !cpu_active(cpu))
+	while (!cpu_online(cpu))
 		cpu_relax();
 
 	return 0;
diff --git a/arch/s390/kernel/smp.c b/arch/s390/kernel/smp.c
index efd2c19..ff890ac 100644
--- a/arch/s390/kernel/smp.c
+++ b/arch/s390/kernel/smp.c
@@ -819,7 +819,7 @@ int __cpu_up(unsigned int cpu, struct task_struct *tidle)
 	pcpu_attach_task(pcpu, tidle);
 	pcpu_start_fn(pcpu, smp_start_secondary, NULL);
 	/* Wait until cpu puts itself in the online & active maps */
-	while (!cpu_online(cpu) || !cpu_active(cpu))
+	while (!cpu_online(cpu))
 		cpu_relax();
 	return 0;
 }

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