Re: [PATCH] fix init_idle() locking problem

[Ingo Molnar]

* Bjorn Helgaas <bjorn.helgaas@xxxxxx> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/