Re: [PATCH] fix init_idle() locking problem

[Ingo Molnar <mingo@elte.hu>]

* Bjorn Helgaas <bjorn.helgaas@hp.com> wrote:

> When starting up secondary CPUs, most architectures do something like
> this:
> 
> 	do_boot_cpu(int cpu)
> 	{
> 		idle = fork_by_hand();
> 		wake_up_forked_process(idle);
> 		init_idle(idle, cpu);
> 
> init_idle() removes "idle" from its runqueue, but there's a window
> between looking up the runqueue and locking it, where another CPU can
> move "idle" to a different runqueue, i.e., via load_balance().

the sched-domains patches that are now in BK solve this problem in a
cleaner way: the rule is that no cross-CPU balancing is allowed until
all CPUs have booted up.

This is enforced by having a boot-time sched-domains tree (initialized
very early on, prior setting up any IRQ sources, in sched_init()), that
isolates each and every CPU from each other - so load_balance() cannot
balance away an idle task. Once all CPUs have booted up the arch can
'cross-connect' all the CPUs and scheduling will begin for real.

this two-phase approach enabled us to reduce alot of the early-boot
scheduling nastiness.

[ btw., your patch does not seem to be correct anyway - if an online CPU
'steals' the new idle task then it will also most likely run it - and
that is disastrous for any CLONE_IDLETASK task. (e.g. on x86 the EIP has
random content, most likely crashing that CPU.) ]

the hotplug CPU code of course must be (and is) extra careful about
installing the new idle task.

	Ingo