On Sat, 27 Feb 2016, Paul E. McKenney wrote:

On Sat, Feb 27, 2016 at 08:47:41AM +0100, Thomas Gleixner wrote:

quoted

On Fri, 26 Feb 2016, Paul E. McKenney wrote:

quoted

quoted

quoted

--- a/kernel/cpu.c
+++ b/kernel/cpu.c

@@ -762,6 +762,7 @@ void cpuhp_report_idle_dead(void)
 	BUG_ON(st->state != CPUHP_AP_OFFLINE);
 	st->state = CPUHP_AP_IDLE_DEAD;
 	complete(&st->done);

What prevents the other CPU from killing this CPU at this point, so
that this CPU does not tell RCU that it is dead?

I agree that the odds should be low, but there are all manner of things
that might delay a CPU for just a little bit too long...

Or am I missing something subtle here?

No. The reason why I moved the rcu call past the complete is, that otherwise
complete() complains about rcu being dead already. Hmm, but you are right. In
theory the other side could allow physical removal before it actually told rcu
that it's gone.

There is one case where this is OK, and that is where the outgoing CPU
puts itself to sleep (or whatever) without help from the other CPU.

That's the case. It's the last call before the outgoing CPU goes into
arch_cpu_idle_dead(). There is no involvement of the controlling CPU at this
point. It just wants to know, that the outgoing one is dead finally.

Thanks,

	tglx