Merge branch 'rcu/next' of...

		when publicizing a pointer to a structure that can

		be traversed by an RCU read-side critical section.

5.	If call_rcu(), or a related primitive such as call_rcu_bh() or

	call_rcu_sched(), is used, the callback function must be

	written to be called from softirq context.  In particular,

5.	If call_rcu(), or a related primitive such as call_rcu_bh(),

	call_rcu_sched(), or call_srcu() is used, the callback function

	must be written to be called from softirq context.  In particular,

	it cannot block.

6.	Since synchronize_rcu() can block, it cannot be called from

	updater uses call_rcu_sched() or synchronize_sched(), then

	the corresponding readers must disable preemption, possibly

	by calling rcu_read_lock_sched() and rcu_read_unlock_sched().

	If the updater uses synchronize_srcu(), the the corresponding

	readers must use srcu_read_lock() and srcu_read_unlock(),

	and with the same srcu_struct.	The rules for the expedited

	primitives are the same as for their non-expedited counterparts.

	Mixing things up will result in confusion and broken kernels.

	If the updater uses synchronize_srcu() or call_srcu(),

	the the corresponding readers must use srcu_read_lock() and

	srcu_read_unlock(), and with the same srcu_struct.  The rules for

	the expedited primitives are the same as for their non-expedited

	counterparts.  Mixing things up will result in confusion and

	broken kernels.

	One exception to this rule: rcu_read_lock() and rcu_read_unlock()

	may be substituted for rcu_read_lock_bh() and rcu_read_unlock_bh()

	victim CPU from ever going offline.)

14.	SRCU (srcu_read_lock(), srcu_read_unlock(), srcu_dereference(),

	synchronize_srcu(), and synchronize_srcu_expedited()) may only

	be invoked from process context.  Unlike other forms of RCU, it

	-is- permissible to block in an SRCU read-side critical section

	(demarked by srcu_read_lock() and srcu_read_unlock()), hence the

	"SRCU": "sleepable RCU".  Please note that if you don't need

	to sleep in read-side critical sections, you should be using

	RCU rather than SRCU, because RCU is almost always faster and

	easier to use than is SRCU.

	synchronize_srcu(), synchronize_srcu_expedited(), and call_srcu())

	may only be invoked from process context.  Unlike other forms of

	RCU, it -is- permissible to block in an SRCU read-side critical

	section (demarked by srcu_read_lock() and srcu_read_unlock()),

	hence the "SRCU": "sleepable RCU".  Please note that if you

	don't need to sleep in read-side critical sections, you should be

	using RCU rather than SRCU, because RCU is almost always faster

	and easier to use than is SRCU.

	If you need to enter your read-side critical section in a

	hardirq or exception handler, and then exit that same read-side

	cleanup_srcu_struct().	These are passed a "struct srcu_struct"

	that defines the scope of a given SRCU domain.	Once initialized,

	the srcu_struct is passed to srcu_read_lock(), srcu_read_unlock()

	synchronize_srcu(), and synchronize_srcu_expedited().  A given

	synchronize_srcu() waits only for SRCU read-side critical

	synchronize_srcu(), synchronize_srcu_expedited(), and call_srcu().

	A given synchronize_srcu() waits only for SRCU read-side critical

	sections governed by srcu_read_lock() and srcu_read_unlock()

	calls that have been passed the same srcu_struct.  This property

	is what makes sleeping read-side critical sections tolerable --

	requiring SRCU's read-side deadlock immunity or low read-side

	realtime latency.

	Note that, rcu_assign_pointer() relates to SRCU just as they do

	Note that, rcu_assign_pointer() relates to SRCU just as it does

	to other forms of RCU.

15.	The whole point of call_rcu(), synchronize_rcu(), and friends

   2. Execute rcu_barrier().

   3. Allow the module to be unloaded.

Quick Quiz #1: Why is there no srcu_barrier()?

The rcutorture module makes use of rcu_barrier in its exit function

as follows:

Then lines 55-62 print status and do operation-specific cleanup, and

then return, permitting the module-unload operation to be completed.

Quick Quiz #2: Is there any other situation where rcu_barrier() might

Quick Quiz #1: Is there any other situation where rcu_barrier() might

	be required?

Your module might have additional complications. For example, if your

 4 complete(&rcu_barrier_completion);

 5 }

Quick Quiz #3: What happens if CPU 0's rcu_barrier_func() executes

Quick Quiz #2: What happens if CPU 0's rcu_barrier_func() executes

	immediately (thus incrementing rcu_barrier_cpu_count to the

	value one), but the other CPU's rcu_barrier_func() invocations

	are delayed for a full grace period? Couldn't this result in

Answers to Quick Quizzes

Quick Quiz #1: Why is there no srcu_barrier()?

Answer: Since there is no call_srcu(), there can be no outstanding SRCU

	callbacks. Therefore, there is no need to wait for them.

Quick Quiz #2: Is there any other situation where rcu_barrier() might

Quick Quiz #1: Is there any other situation where rcu_barrier() might

	be required?

Answer: Interestingly enough, rcu_barrier() was not originally

	implementing rcutorture, and found that rcu_barrier() solves

	this problem as well.

Quick Quiz #3: What happens if CPU 0's rcu_barrier_func() executes

Quick Quiz #2: What happens if CPU 0's rcu_barrier_func() executes

	immediately (thus incrementing rcu_barrier_cpu_count to the

	value one), but the other CPU's rcu_barrier_func() invocations

	are delayed for a full grace period? Couldn't this result in

			and synchronize_rcu_bh_expedited().

		"srcu": srcu_read_lock(), srcu_read_unlock() and

			call_srcu().

		"srcu_sync": srcu_read_lock(), srcu_read_unlock() and

			synchronize_srcu().

		"srcu_expedited": srcu_read_lock(), srcu_read_unlock() and

			synchronize_srcu_expedited().

		"srcu_raw": srcu_read_lock_raw(), srcu_read_unlock_raw(),

			and call_srcu().

		"srcu_raw_sync": srcu_read_lock_raw(), srcu_read_unlock_raw(),

			and synchronize_srcu().

		"sched": preempt_disable(), preempt_enable(), and

			call_rcu_sched().

SRCU:	Critical sections	Grace period		Barrier

	srcu_read_lock		synchronize_srcu	N/A

	srcu_read_unlock	synchronize_srcu_expedited

	srcu_read_lock_raw

	srcu_read_lock		synchronize_srcu	srcu_barrier

	srcu_read_unlock	call_srcu

	srcu_read_lock_raw	synchronize_srcu_expedited

	srcu_read_unlock_raw

	srcu_dereference

			Set maximum number of finished RCU callbacks to process

			in one batch.

	rcutree.fanout_leaf=	[KNL,BOOT]

			Increase the number of CPUs assigned to each

			leaf rcu_node structure.  Useful for very large

			systems.

	rcutree.qhimark=	[KNL,BOOT]

			Set threshold of queued

			RCU callbacks over which batch limiting is disabled.