mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
synced 2024-12-28 16:52:18 +00:00
ec9d6356bf
This commit adds reader-state debugging checks to a new function named rcutorture_one_extend_check(), which is invoked before and after setting new reader states by the existing rcutorture_one_extend() function. These checks have proven to be rather heavyweight, reducing reproduction rate of some failures by a factor of two. They are therefore hidden behind a new RCU_TORTURE_TEST_CHK_RDR_STATE Kconfig option. Signed-off-by: Paul E. McKenney <paulmck@kernel.org> Cc: Frederic Weisbecker <frederic@kernel.org> Tested-by: kernel test robot <oliver.sang@intel.com> Signed-off-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
203 lines
7.1 KiB
Plaintext
203 lines
7.1 KiB
Plaintext
# SPDX-License-Identifier: GPL-2.0-only
|
|
#
|
|
# RCU-related debugging configuration options
|
|
#
|
|
|
|
menu "RCU Debugging"
|
|
|
|
config PROVE_RCU
|
|
def_bool PROVE_LOCKING
|
|
|
|
config PROVE_RCU_LIST
|
|
bool "RCU list lockdep debugging"
|
|
depends on PROVE_RCU && RCU_EXPERT
|
|
default n
|
|
help
|
|
Enable RCU lockdep checking for list usages. By default it is
|
|
turned off since there are several list RCU users that still
|
|
need to be converted to pass a lockdep expression. To prevent
|
|
false-positive splats, we keep it default disabled but once all
|
|
users are converted, we can remove this config option.
|
|
|
|
config TORTURE_TEST
|
|
tristate
|
|
default n
|
|
|
|
config RCU_SCALE_TEST
|
|
tristate "performance tests for RCU"
|
|
depends on DEBUG_KERNEL
|
|
select TORTURE_TEST
|
|
default n
|
|
help
|
|
This option provides a kernel module that runs performance
|
|
tests on the RCU infrastructure. The kernel module may be built
|
|
after the fact on the running kernel to be tested, if desired.
|
|
|
|
Say Y here if you want RCU performance tests to be built into
|
|
the kernel.
|
|
Say M if you want the RCU performance tests to build as a module.
|
|
Say N if you are unsure.
|
|
|
|
config RCU_TORTURE_TEST
|
|
tristate "torture tests for RCU"
|
|
depends on DEBUG_KERNEL
|
|
select TORTURE_TEST
|
|
default n
|
|
help
|
|
This option provides a kernel module that runs torture tests
|
|
on the RCU infrastructure. The kernel module may be built
|
|
after the fact on the running kernel to be tested, if desired.
|
|
|
|
Say Y here if you want RCU torture tests to be built into
|
|
the kernel.
|
|
Say M if you want the RCU torture tests to build as a module.
|
|
Say N if you are unsure.
|
|
|
|
config RCU_TORTURE_TEST_CHK_RDR_STATE
|
|
tristate "Check rcutorture reader state"
|
|
depends on RCU_TORTURE_TEST
|
|
default n
|
|
help
|
|
This option causes rcutorture to check the desired rcutorture
|
|
reader state for each segment against the actual context.
|
|
Note that PREEMPT_COUNT must be enabled if the preempt-disabled
|
|
and bh-disabled checks are to take effect, and that PREEMPT_RCU
|
|
must be enabled for the RCU-nesting checks to take effect.
|
|
These checks add overhead, and this Kconfig options is therefore
|
|
disabled by default.
|
|
|
|
Say Y here if you want rcutorture reader contexts checked.
|
|
Say N if you are unsure.
|
|
|
|
config RCU_TORTURE_TEST_LOG_CPU
|
|
tristate "Log CPU for rcutorture failures"
|
|
depends on RCU_TORTURE_TEST
|
|
default n
|
|
help
|
|
This option causes rcutorture to decorate each entry of its
|
|
log of failure/close-call rcutorture reader segments with the
|
|
number of the CPU that the reader was running on at the time.
|
|
This information can be useful, but it does incur additional
|
|
overhead, overhead that can make both failures and close calls
|
|
less probable.
|
|
|
|
Say Y here if you want CPU IDs logged.
|
|
Say N if you are unsure.
|
|
|
|
config RCU_REF_SCALE_TEST
|
|
tristate "Scalability tests for read-side synchronization (RCU and others)"
|
|
depends on DEBUG_KERNEL
|
|
select TORTURE_TEST
|
|
default n
|
|
help
|
|
This option provides a kernel module that runs performance tests
|
|
useful comparing RCU with various read-side synchronization mechanisms.
|
|
The kernel module may be built after the fact on the running kernel to be
|
|
tested, if desired.
|
|
|
|
Say Y here if you want these performance tests built into the kernel.
|
|
Say M if you want to build it as a module instead.
|
|
Say N if you are unsure.
|
|
|
|
config RCU_CPU_STALL_TIMEOUT
|
|
int "RCU CPU stall timeout in seconds"
|
|
depends on RCU_STALL_COMMON
|
|
range 3 300
|
|
default 21
|
|
help
|
|
If a given RCU grace period extends more than the specified
|
|
number of seconds, a CPU stall warning is printed. If the
|
|
RCU grace period persists, additional CPU stall warnings are
|
|
printed at more widely spaced intervals.
|
|
|
|
config RCU_EXP_CPU_STALL_TIMEOUT
|
|
int "Expedited RCU CPU stall timeout in milliseconds"
|
|
depends on RCU_STALL_COMMON
|
|
range 0 300000
|
|
default 0
|
|
help
|
|
If a given expedited RCU grace period extends more than the
|
|
specified number of milliseconds, a CPU stall warning is printed.
|
|
If the RCU grace period persists, additional CPU stall warnings
|
|
are printed at more widely spaced intervals. A value of zero
|
|
says to use the RCU_CPU_STALL_TIMEOUT value converted from
|
|
seconds to milliseconds.
|
|
|
|
config RCU_CPU_STALL_CPUTIME
|
|
bool "Provide additional RCU stall debug information"
|
|
depends on RCU_STALL_COMMON
|
|
default n
|
|
help
|
|
Collect statistics during the sampling period, such as the number of
|
|
(hard interrupts, soft interrupts, task switches) and the cputime of
|
|
(hard interrupts, soft interrupts, kernel tasks) are added to the
|
|
RCU stall report. For multiple continuous RCU stalls, all sampling
|
|
periods begin at half of the first RCU stall timeout.
|
|
The boot option rcupdate.rcu_cpu_stall_cputime has the same function
|
|
as this one, but will override this if it exists.
|
|
|
|
config RCU_CPU_STALL_NOTIFIER
|
|
bool "Provide RCU CPU-stall notifiers"
|
|
depends on RCU_STALL_COMMON
|
|
depends on DEBUG_KERNEL
|
|
depends on RCU_EXPERT
|
|
default n
|
|
help
|
|
WARNING: You almost certainly do not want this!!!
|
|
|
|
Enable RCU CPU-stall notifiers, which are invoked just before
|
|
printing the RCU CPU stall warning. As such, bugs in notifier
|
|
callbacks can prevent stall warnings from being printed.
|
|
And the whole reason that a stall warning is being printed is
|
|
that something is hung up somewhere. Therefore, the notifier
|
|
callbacks must be written extremely carefully, preferably
|
|
containing only lockless code. After all, it is quite possible
|
|
that the whole reason that the RCU CPU stall is happening in
|
|
the first place is that someone forgot to release whatever lock
|
|
that you are thinking of acquiring. In which case, having your
|
|
notifier callback acquire that lock will hang, preventing the
|
|
RCU CPU stall warning from appearing.
|
|
|
|
Say Y here if you want RCU CPU stall notifiers (you don't want them)
|
|
Say N if you are unsure.
|
|
|
|
config RCU_TRACE
|
|
bool "Enable tracing for RCU"
|
|
depends on DEBUG_KERNEL
|
|
default y if TREE_RCU
|
|
select TRACE_CLOCK
|
|
help
|
|
This option enables additional tracepoints for ftrace-style
|
|
event tracing.
|
|
|
|
Say Y here if you want to enable RCU tracing
|
|
Say N if you are unsure.
|
|
|
|
config RCU_EQS_DEBUG
|
|
bool "Provide debugging asserts for adding NO_HZ support to an arch"
|
|
depends on DEBUG_KERNEL
|
|
help
|
|
This option provides consistency checks in RCU's handling of
|
|
NO_HZ. These checks have proven quite helpful in detecting
|
|
bugs in arch-specific NO_HZ code.
|
|
|
|
Say N here if you need ultimate kernel/user switch latencies
|
|
Say Y if you are unsure
|
|
|
|
config RCU_STRICT_GRACE_PERIOD
|
|
bool "Provide debug RCU implementation with short grace periods"
|
|
depends on DEBUG_KERNEL && RCU_EXPERT && NR_CPUS <= 4 && !TINY_RCU
|
|
default n
|
|
select PREEMPT_COUNT if PREEMPT=n
|
|
help
|
|
Select this option to build an RCU variant that is strict about
|
|
grace periods, making them as short as it can. This limits
|
|
scalability, destroys real-time response, degrades battery
|
|
lifetime and kills performance. Don't try this on large
|
|
machines, as in systems with more than about 10 or 20 CPUs.
|
|
But in conjunction with tools like KASAN, it can be helpful
|
|
when looking for certain types of RCU usage bugs, for example,
|
|
too-short RCU read-side critical sections.
|
|
|
|
endmenu # "RCU Debugging"
|