Documentation/RCU: Fix emphasis markers

1.	Does the update code have proper mutual exclusion?

	RCU does allow -readers- to run (almost) naked, but -writers- must

	RCU does allow *readers* to run (almost) naked, but *writers* must

	still use some sort of mutual exclusion, such as:

	a.	locking,

	critical section is every bit as bad as letting them leak out

	from under a lock.  Unless, of course, you have arranged some

	other means of protection, such as a lock or a reference count

	-before- letting them out of the RCU read-side critical section.

	*before* letting them out of the RCU read-side critical section.

3.	Does the update code tolerate concurrent accesses?

	c.	Make updates appear atomic to readers.	For example,

		pointer updates to properly aligned fields will

		appear atomic, as will individual atomic primitives.

		Sequences of operations performed under a lock will -not-

		Sequences of operations performed under a lock will *not*

		appear to be atomic to RCU readers, nor will sequences

		of multiple atomic primitives.

	for example) may be omitted.

10.	Conversely, if you are in an RCU read-side critical section,

	and you don't hold the appropriate update-side lock, you -must-

	and you don't hold the appropriate update-side lock, you *must*

	use the "_rcu()" variants of the list macros.  Failing to do so

	will break Alpha, cause aggressive compilers to generate bad code,

	and confuse people trying to read your code.

	callback pending, then that RCU callback will execute on some

	surviving CPU.	(If this was not the case, a self-spawning RCU

	callback would prevent the victim CPU from ever going offline.)

	Furthermore, CPUs designated by rcu_nocbs= might well -always-

	Furthermore, CPUs designated by rcu_nocbs= might well *always*

	have their RCU callbacks executed on some other CPUs, in fact,

	for some  real-time workloads, this is the whole point of using

	the rcu_nocbs= kernel boot parameter.

13.	Unlike other forms of RCU, it -is- permissible to block in an

13.	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

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

	is to wait until all pre-existing readers have finished before

	carrying out some otherwise-destructive operation.  It is

	therefore critically important to -first- remove any path

	therefore critically important to *first* remove any path

	that readers can follow that could be affected by the

	destructive operation, and -only- -then- invoke call_rcu(),

	destructive operation, and *only then* invoke call_rcu(),

	synchronize_rcu(), or friends.

	Because these primitives only wait for pre-existing readers, it

	is the caller's responsibility to guarantee that any subsequent

	readers will execute safely.

15.	The various RCU read-side primitives do -not- necessarily contain

15.	The various RCU read-side primitives do *not* necessarily contain

	memory barriers.  You should therefore plan for the CPU

	and the compiler to freely reorder code into and out of RCU

	read-side critical sections.  It is the responsibility of the

	pass in a function defined within a loadable module, then it in

	necessary to wait for all pending callbacks to be invoked after

	the last invocation and before unloading that module.  Note that

	it is absolutely -not- sufficient to wait for a grace period!

	The current (say) synchronize_rcu() implementation is -not-

	it is absolutely *not* sufficient to wait for a grace period!

	The current (say) synchronize_rcu() implementation is *not*

	guaranteed to wait for callbacks registered on other CPUs.

	Or even on the current CPU if that CPU recently went offline

	and came back online.

	-	call_rcu() -> rcu_barrier()

	-	call_srcu() -> srcu_barrier()

	However, these barrier functions are absolutely -not- guaranteed

	However, these barrier functions are absolutely *not* guaranteed

	to wait for a grace period.  In fact, if there are no call_rcu()

	callbacks waiting anywhere in the system, rcu_barrier() is within

	its rights to return immediately.

	-	Set bits and clear bits down in the must-be-zero low-order

		bits of that pointer.  This clearly means that the pointer

		must have alignment constraints, for example, this does

		-not- work in general for char* pointers.

		*not* work in general for char* pointers.

	-	XOR bits to translate pointers, as is done in some

		classic buddy-allocator algorithms.

		Please see the "CONTROL DEPENDENCIES" section of

		Documentation/memory-barriers.txt for more details.

	-	The pointers are not equal -and- the compiler does

	-	The pointers are not equal *and* the compiler does

		not have enough information to deduce the value of the

		pointer.  Note that the volatile cast in rcu_dereference()

		will normally prevent the compiler from knowing too much.

return values.  This can result in "p->b" returning pre-initialization

garbage values.

In short, rcu_dereference() is -not- optional when you are going to

In short, rcu_dereference() is *not* optional when you are going to

dereference the resulting pointer.

-	Booting Linux using a console connection that is too slow to

	keep up with the boot-time console-message rate.  For example,

	a 115Kbaud serial console can be -way- too slow to keep up

	a 115Kbaud serial console can be *way* too slow to keep up

	with boot-time message rates, and will frequently result in

	RCU CPU stall warning messages.  Especially if you have added

	debug printk()s.

	leading the realization that the CPU had failed.

The RCU, RCU-sched, and RCU-tasks implementations have CPU stall warning.

Note that SRCU does -not- have CPU stall warnings.  Please note that

Note that SRCU does *not* have CPU stall warnings.  Please note that

RCU only detects CPU stalls when there is a grace period in progress.

No grace period, no CPU stall warnings.

	this parameter is checked only at the beginning of a cycle.

	So if you are 10 seconds into a 40-second stall, setting this

	sysfs parameter to (say) five will shorten the timeout for the

	-next- stall, or the following warning for the current stall

	*next* stall, or the following warning for the current stall

	(assuming the stall lasts long enough).  It will not affect the

	timing of the next warning for the current stall.

will normally be followed by stack dumps for each CPU.  Please note that

PREEMPT_RCU builds can be stalled by tasks as well as by CPUs, and that

the tasks will be indicated by PID, for example, "P3421".  It is even

possible for an rcu_state stall to be caused by both CPUs -and- tasks,

possible for an rcu_state stall to be caused by both CPUs *and* tasks,

in which case the offending CPUs and tasks will all be called out in the list.

CPU 2's "(3 GPs behind)" indicates that this CPU has not interacted with