tree aac29aa8609b9aa253ea6dd2d9b5bef6368a7058
parent 9a08c64a182f237a66b7862082139d95f9bb346a
author Paul E. McKenney <paulmck@linux.vnet.ibm.com> 1501283800 -0700
committer Paul E. McKenney <paulmck@linux.vnet.ibm.com> 1501605734 -0700

rcu: Provide GP ordering in face of migrations and delays

Consider the following admittedly improbable sequence of events:

o	RCU is initially idle.

o	Task A on CPU 0 executes rcu_read_lock().

o	Task B on CPU 1 executes synchronize_rcu(), which must
	wait on Task A:

	o	Task B registers the callback, which starts a new
		grace period, awakening the grace-period kthread
		on CPU 3, which immediately starts a new grace period.

	o	Task B migrates to CPU 2, which provides a quiescent
		state for both CPUs 1 and 2.

	o	Both CPUs 1 and 2 take scheduling-clock interrupts,
		and both invoke RCU_SOFTIRQ, both thus learning of the
		new grace period.

	o	Task B is delayed, perhaps by vCPU preemption on CPU 2.

o	CPUs 2 and 3 pass through quiescent states, which are reported
	to core RCU.

o	Task B is resumed just long enough to be migrated to CPU 3,
	and then is once again delayed.

o	Task A executes rcu_read_unlock(), exiting its RCU read-side
	critical section.

o	CPU 0 passes through a quiescent sate, which is reported to
	core RCU.  Only CPU 1 continues to block the grace period.

o	CPU 1 passes through a quiescent state, which is reported to
	core RCU.  This ends the grace period, and CPU 1 therefore
	invokes its callbacks, one of which awakens Task B via
	complete().

o	Task B resumes (still on CPU 3) and starts executing
	wait_for_completion(), which sees that the completion has
	already completed, and thus does not block.  It returns from
	the synchronize_rcu() without any ordering against the
	end of Task A's RCU read-side critical section.

	It can therefore mess up Task A's RCU read-side critical section,
	in theory, anyway.

However, if CPU hotplug ever gets rid of stop_machine(), there will be
more straightforward ways for this sort of thing to happen, so this
commit adds a memory barrier in order to enforce the needed ordering.

Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>