On Sat, 27 Feb 2016, Brian Gerst wrote:
> > arch_cpu_idle_prepare();
> > cpu_idle_loop();
> > }
>
> Does this actually work with stack protector enabled?
> boot_init_stack_canary() is inlined while arch_cpu_idle_prepare() is
> not.
Stupid me. No it does of course not. I could have sworn that I tested that,
but obvioulsy not.
I drop that patch, but actually the real question is whether we can drop that
'#ifdef x86' around that boot_init_stack_canary() invocation.
AFAICT, neither arm, arm64 nor mips and sh call it on anything else than the
boot cpu. I can't see why that would be an issue on those architectures and
why it would be a problem if the boot cpu calls it again here.
CC'ed the relevant maintainers. Is there any issue with the patch below?
Thanks,
tglx
8<------------------
--- a/kernel/sched/idle.c
+++ b/kernel/sched/idle.c
@@ -276,12 +276,6 @@ static void cpu_idle_loop(void)
void cpu_startup_entry(enum cpuhp_state state)
{
/*
- * This #ifdef needs to die, but it's too late in the cycle to
- * make this generic (arm and sh have never invoked the canary
- * init for the non boot cpus!). Will be fixed in 3.11
- */
-#ifdef CONFIG_X86
- /*
* If we're the non-boot CPU, nothing set the stack canary up
* for us. The boot CPU already has it initialized but no harm
* in doing it again. This is a good place for updating it, as
@@ -289,7 +283,7 @@ void cpu_startup_entry(enum cpuhp_state
* canaries already on the stack wont ever trigger).
*/
boot_init_stack_canary();
-#endif
+
arch_cpu_idle_prepare();
cpu_idle_loop();
}
--
To unsubscribe from this list: send the line "unsubscribe linux-arch" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
