rcu: Update stall-warning documentation

	This kernel configuration parameter defines the period of time

	that RCU will wait from the beginning of a grace period until it

	issues an RCU CPU stall warning.  This time period is normally

	sixty seconds.

	21 seconds.

	This configuration parameter may be changed at runtime via the

	/sys/module/rcutree/parameters/rcu_cpu_stall_timeout, however

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

	So if you are 30 seconds into a 70-second stall, setting this

	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

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

	also dump the stacks of any tasks that are blocking the current

	RCU-preempt grace period.

RCU_CPU_STALL_INFO

CONFIG_RCU_CPU_STALL_INFO

	This kernel configuration parameter causes the stall warning to

	print out additional per-CPU diagnostic information, including

	Although the lockdep facility is extremely useful, it does add

	some overhead.  Therefore, under CONFIG_PROVE_RCU, the

	RCU_STALL_DELAY_DELTA macro allows five extra seconds before

	giving an RCU CPU stall warning message.

	giving an RCU CPU stall warning message.  (This is a cpp

	macro, not a kernel configuration parameter.)

RCU_STALL_RAT_DELAY

	However, if the offending CPU does not detect its own stall in

	the number of jiffies specified by RCU_STALL_RAT_DELAY, then

	some other CPU will complain.  This delay is normally set to

	two jiffies.

	two jiffies.  (This is a cpp macro, not a kernel configuration

	parameter.)

When a CPU detects that it is stalling, it will print a message similar

to the following:

INFO: rcu_bh_state detected stalls on CPUs/tasks: { } (detected by 4, 2502 jiffies)

This is rare, but does happen from time to time in real life.

This is rare, but does happen from time to time in real life.  It is also

possible for a zero-jiffy stall to be flagged in this case, depending

on how the stall warning and the grace-period initialization happen to

interact.  Please note that it is not possible to entirely eliminate this

sort of false positive without resorting to things like stop_machine(),

which is overkill for this sort of problem.

If the CONFIG_RCU_CPU_STALL_INFO kernel configuration parameter is set,

more information is printed with the stall-warning message, for example:

If you can reliably trigger the stall, ftrace can be quite helpful.

RCU bugs can often be debugged with the help of CONFIG_RCU_TRACE

and with RCU's event tracing.

and with RCU's event tracing.  For information on RCU's event tracing,

see include/trace/events/rcu.h.