ARM: smpboot: Enable irqs on secondary CPU after marking it online/active
authorThomas Gleixner <tglx@linutronix.de>
Sat, 15 Oct 2011 00:22:43 +0000 (17:22 -0700)
committerDima Zavin <dima@android.com>
Thu, 20 Oct 2011 20:45:55 +0000 (13:45 -0700)
commitc8bfd7dd2b3587d40664f0a25313ba44617a903f
treec3d98322201a685d01f47bbf2758f832d9e82774
parent8b7fd32923143097928a21b33b6238084072f8f9
ARM: smpboot: Enable irqs on secondary CPU after marking it online/active

Patch is the last version from tglx on Oct 7.

Discussion is at: http://comments.gmane.org/gmane.linux.ports.arm.kernel/131919

The original commit message for the first patch version:

Frank Rowand reported:

 I have a consistent (every boot) hang on boot with the RT patches.
 With a few hacks to get console output, I get:

  rcu_preempt_state detected stalls on CPUs/tasks

 I have also replicated the problem on the ARM RealView (in tree) and
 without the RT patches.

 The problem ended up being caused by the allowed cpus mask being set
 to all possible cpus for the ksoftirqd on the secondary processors.
 So the RCU softirq was never executing on the secondary cpu.

 The problem was that ksoftirqd was woken on the secondary processors before
 the secondary processors were online. This led to allowed cpus being set
 to all cpus.

   wake_up_process()
      try_to_wake_up()
         select_task_rq()
            if (... || !cpu_online(cpu))
               select_fallback_rq(task_cpu(p), p)
                  ...
                  /* No more Mr. Nice Guy. */
                  dest_cpu = cpuset_cpus_allowed_fallback(p)
                     do_set_cpus_allowed(p, cpu_possible_mask)
                        #  Thus ksoftirqd can now run on any cpu...
</report>

The reason is that the ARM SMP boot code for the secondary CPUs enables
interrupts before the newly brought up CPU is marked online and
active.

That causes a wakeup of ksoftirqd or a wakeup of any other kernel
thread which is affine to the brought up CPU break that threads
affinity and therefor being scheduled on already online CPUs.

This problem has been observed on x86 before and the only solution is
to mark the CPU online and wait for the CPU active bit before the
point where interrupts are enabled.

Change-Id: If948ef52d434191579e1ca95d18d0c50e91a03b9
Signed-off-by: Dima Zavin <dima@android.com>
arch/arm/kernel/smp.c