linux-kernel - [PATCH 48/79] [PATCH] boot cpus from cpu_up, instead of prepare

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]

Message-Id: <12059477922945-git-send-email-gcosta@redhat.com>
Date:	Wed, 19 Mar 2008 14:25:43 -0300
From:	Glauber de Oliveira Costa <gcosta@...hat.com>
To:	linux-kernel@...r.kernel.org
Cc:	akpm@...ux-foundation.org, tglx@...utronix.de, mingo@...e.hu,
	ak@...e.de, Glauber Costa <gcosta@...hat.com>
Subject: [PATCH 48/79] [PATCH] boot cpus from cpu_up, instead of prepare_cpus

From: Glauber Costa <gcosta@...hat.com>

After all the infrastructure work, we're now prepared
to boot the cpus from cpu_up, and not from prepare_cpus.
So the difference between cold boot and hotplug is effectively
over, and the functions are used to the purposes they're meant to.

Signed-off-by: Glauber Costa <gcosta@...hat.com>
---
 arch/x86/kernel/smpboot_32.c |   48 +----------------------------------------
 1 files changed, 2 insertions(+), 46 deletions(-)

diff --git a/arch/x86/kernel/smpboot_32.c b/arch/x86/kernel/smpboot_32.c
index 88ee655..978e137 100644
--- a/arch/x86/kernel/smpboot_32.c
+++ b/arch/x86/kernel/smpboot_32.c
@@ -670,6 +670,7 @@ void cpu_exit_clear(void)
 	cpu_clear(cpu, smp_commenced_mask);
 	unmap_cpu_to_logical_apicid(cpu);
 }
+#endif
 
 struct warm_boot_cpu_info {
 	struct completion *complete;
@@ -710,7 +711,6 @@ static void __cpuinit __smp_prepare_cpu(int cpu)
 		wait_for_completion(&done);
 	}
 }
-#endif
 
 static int boot_cpu_logical_apicid;
 /* Where the IO area was mapped on multiquad, always 0 otherwise */
@@ -790,8 +790,6 @@ static int __init smp_sanity_check(unsigned max_cpus)
  */
 static void __init smp_boot_cpus(unsigned int max_cpus)
 {
-	int apicid, cpu, bit, kicked;
-
 	/*
 	 * Setup boot CPU information
 	 */
@@ -819,39 +817,6 @@ static void __init smp_boot_cpus(unsigned int max_cpus)
 
 	setup_portio_remap();
 
-	/*
-	 * Scan the CPU present map and fire up the other CPUs via do_boot_cpu
-	 *
-	 * In clustered apic mode, phys_cpu_present_map is a constructed thus:
-	 * bits 0-3 are quad0, 4-7 are quad1, etc. A perverse twist on the 
-	 * clustered apic ID.
-	 */
-	Dprintk("CPU present map: %lx\n", physids_coerce(phys_cpu_present_map));
-
-	kicked = 1;
-	for (bit = 0; kicked < NR_CPUS && bit < MAX_APICS; bit++) {
-		apicid = cpu_present_to_apicid(bit);
-		/*
-		 * Don't even attempt to start the boot CPU!
-		 */
-		if ((apicid == boot_cpu_apicid) || (apicid == BAD_APICID))
-			continue;
-
-		if (!check_apicid_present(bit))
-			continue;
-		if (max_cpus <= cpus_weight(cpu_present_map))
-			continue;
-		/* Utterly temporary */
-		for (cpu = 0; cpu < NR_CPUS; cpu++)
-			if (per_cpu(x86_cpu_to_apicid, cpu) == apicid)
-				break;
-		if (do_boot_cpu(apicid, cpu))
-			printk("CPU #%d not responding - cannot use it.\n",
-								apicid);
-		else
-			++kicked;
-	}
-
 	smpboot_setup_io_apic();
 
 	setup_boot_clock();
@@ -895,17 +860,8 @@ int __cpuinit native_cpu_up(unsigned int cpu)
 	}
 
 	per_cpu(cpu_state, cpu) = CPU_UP_PREPARE;
-#ifdef CONFIG_HOTPLUG_CPU
 
-	/*
-	 * We do warm boot only on cpus that had booted earlier
-	 * Otherwise cold boot is all handled from smp_boot_cpus().
-	 * cpu_callin_map is set during AP kickstart process. Its reset
-	 * when a cpu is taken offline from cpu_exit_clear().
-	 */
-	if (!cpu_isset(cpu, cpu_callin_map))
-		__smp_prepare_cpu(cpu);
-#endif
+	__smp_prepare_cpu(cpu);
 
 	/* In case one didn't come up */
 	if (!cpu_isset(cpu, cpu_callin_map)) {
-- 
1.5.0.6

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