x86: provide an init_mem_mapping hypervisor hook

[karo-tx-linux.git] / lib / Kconfig.debug

diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index ca9460f049b82ff8535521d94bed95ec87d0ce21..98fe715522e8d1834083e608d32a78ed0600deb9 100644 (file)
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -778,34 +778,45 @@ config DEBUG_SHIRQ
 menu "Debug Lockups and Hangs"
 
 config LOCKUP_DETECTOR
 menu "Debug Lockups and Hangs"
 
 config LOCKUP_DETECTOR

-       bool "Detect Hard and Soft Lockups"
+       bool
+
+config SOFTLOCKUP_DETECTOR
+       bool "Detect Soft Lockups"

        depends on DEBUG_KERNEL && !S390
        depends on DEBUG_KERNEL && !S390

+       select LOCKUP_DETECTOR

        help
          Say Y here to enable the kernel to act as a watchdog to detect
        help
          Say Y here to enable the kernel to act as a watchdog to detect

-         hard and soft lockups.
+         soft lockups.

 
          Softlockups are bugs that cause the kernel to loop in kernel
          mode for more than 20 seconds, without giving other tasks a
          chance to run.  The current stack trace is displayed upon
          detection and the system will stay locked up.
 
 
          Softlockups are bugs that cause the kernel to loop in kernel
          mode for more than 20 seconds, without giving other tasks a
          chance to run.  The current stack trace is displayed upon
          detection and the system will stay locked up.
 

+config HARDLOCKUP_DETECTOR_PERF
+       bool
+       select SOFTLOCKUP_DETECTOR
+
+#
+# arch/ can define HAVE_HARDLOCKUP_DETECTOR_ARCH to provide their own hard
+# lockup detector rather than the perf based detector.
+#
+config HARDLOCKUP_DETECTOR
+       bool "Detect Hard Lockups"
+       depends on DEBUG_KERNEL && !S390
+       depends on HAVE_HARDLOCKUP_DETECTOR_PERF || HAVE_HARDLOCKUP_DETECTOR_ARCH
+       select LOCKUP_DETECTOR
+       select HARDLOCKUP_DETECTOR_PERF if HAVE_HARDLOCKUP_DETECTOR_PERF
+       select HARDLOCKUP_DETECTOR_ARCH if HAVE_HARDLOCKUP_DETECTOR_ARCH
+       help
+         Say Y here to enable the kernel to act as a watchdog to detect
+         hard lockups.
+

          Hardlockups are bugs that cause the CPU to loop in kernel mode
          for more than 10 seconds, without letting other interrupts have a
          chance to run.  The current stack trace is displayed upon detection
          and the system will stay locked up.
 
          Hardlockups are bugs that cause the CPU to loop in kernel mode
          for more than 10 seconds, without letting other interrupts have a
          chance to run.  The current stack trace is displayed upon detection
          and the system will stay locked up.
 

-         The overhead should be minimal.  A periodic hrtimer runs to
-         generate interrupts and kick the watchdog task every 4 seconds.
-         An NMI is generated every 10 seconds or so to check for hardlockups.
-
-         The frequency of hrtimer and NMI events and the soft and hard lockup
-         thresholds can be controlled through the sysctl watchdog_thresh.
-
-config HARDLOCKUP_DETECTOR
-       def_bool y
-       depends on LOCKUP_DETECTOR && !HAVE_NMI_WATCHDOG
-       depends on PERF_EVENTS && HAVE_PERF_EVENTS_NMI
-

 config BOOTPARAM_HARDLOCKUP_PANIC
        bool "Panic (Reboot) On Hard Lockups"
        depends on HARDLOCKUP_DETECTOR
 config BOOTPARAM_HARDLOCKUP_PANIC
        bool "Panic (Reboot) On Hard Lockups"
        depends on HARDLOCKUP_DETECTOR


@@ -826,7 +837,7 @@ config BOOTPARAM_HARDLOCKUP_PANIC_VALUE
 
 config BOOTPARAM_SOFTLOCKUP_PANIC
        bool "Panic (Reboot) On Soft Lockups"
 
 config BOOTPARAM_SOFTLOCKUP_PANIC
        bool "Panic (Reboot) On Soft Lockups"

-       depends on LOCKUP_DETECTOR
+       depends on SOFTLOCKUP_DETECTOR

        help
          Say Y here to enable the kernel to panic on "soft lockups",
          which are bugs that cause the kernel to loop in kernel
        help
          Say Y here to enable the kernel to panic on "soft lockups",
          which are bugs that cause the kernel to loop in kernel


@@ -843,7 +854,7 @@ config BOOTPARAM_SOFTLOCKUP_PANIC
 
 config BOOTPARAM_SOFTLOCKUP_PANIC_VALUE
        int
 
 config BOOTPARAM_SOFTLOCKUP_PANIC_VALUE
        int

-       depends on LOCKUP_DETECTOR
+       depends on SOFTLOCKUP_DETECTOR

        range 0 1
        default 0 if !BOOTPARAM_SOFTLOCKUP_PANIC
        default 1 if BOOTPARAM_SOFTLOCKUP_PANIC
        range 0 1
        default 0 if !BOOTPARAM_SOFTLOCKUP_PANIC
        default 1 if BOOTPARAM_SOFTLOCKUP_PANIC


@@ -851,7 +862,7 @@ config BOOTPARAM_SOFTLOCKUP_PANIC_VALUE
 config DETECT_HUNG_TASK
        bool "Detect Hung Tasks"
        depends on DEBUG_KERNEL
 config DETECT_HUNG_TASK
        bool "Detect Hung Tasks"
        depends on DEBUG_KERNEL

-       default LOCKUP_DETECTOR
+       default SOFTLOCKUP_DETECTOR

        help
          Say Y here to enable the kernel to detect "hung tasks",
          which are bugs that cause the task to be stuck in
        help
          Say Y here to enable the kernel to detect "hung tasks",
          which are bugs that cause the task to be stuck in


@@ -1212,6 +1223,34 @@ config STACKTRACE
          It is also used by various kernel debugging features that require
          stack trace generation.
 
          It is also used by various kernel debugging features that require
          stack trace generation.
 

+config WARN_ALL_UNSEEDED_RANDOM
+       bool "Warn for all uses of unseeded randomness"
+       default n
+       help
+         Some parts of the kernel contain bugs relating to their use of
+         cryptographically secure random numbers before it's actually possible
+         to generate those numbers securely. This setting ensures that these
+         flaws don't go unnoticed, by enabling a message, should this ever
+         occur. This will allow people with obscure setups to know when things
+         are going wrong, so that they might contact developers about fixing
+         it.
+
+         Unfortunately, on some models of some architectures getting
+         a fully seeded CRNG is extremely difficult, and so this can
+         result in dmesg getting spammed for a surprisingly long
+         time.  This is really bad from a security perspective, and
+         so architecture maintainers really need to do what they can
+         to get the CRNG seeded sooner after the system is booted.
+         However, since users can not do anything actionble to
+         address this, by default the kernel will issue only a single
+         warning for the first use of unseeded randomness.
+
+         Say Y here if you want to receive warnings for all uses of
+         unseeded randomness.  This will be of use primarily for
+         those developers interersted in improving the security of
+         Linux kernels running on their architecture (or
+         subarchitecture).
+

 config DEBUG_KOBJECT
        bool "kobject debugging"
        depends on DEBUG_KERNEL
 config DEBUG_KOBJECT
        bool "kobject debugging"
        depends on DEBUG_KERNEL


@@ -1594,7 +1633,7 @@ config RBTREE_TEST
 
 config INTERVAL_TREE_TEST
        tristate "Interval tree test"
 
 config INTERVAL_TREE_TEST
        tristate "Interval tree test"

-       depends on m && DEBUG_KERNEL
+       depends on DEBUG_KERNEL

        select INTERVAL_TREE
        help
          A benchmark measuring the performance of the interval tree library
        select INTERVAL_TREE
        help
          A benchmark measuring the performance of the interval tree library


@@ -1785,6 +1824,17 @@ config TEST_FIRMWARE
 
          If unsure, say N.
 
 
          If unsure, say N.
 

+config TEST_SYSCTL
+       tristate "sysctl test driver"
+       default n
+       depends on PROC_SYSCTL
+       help
+         This builds the "test_sysctl" module. This driver enables to test the
+         proc sysctl interfaces available to drivers safely without affecting
+         production knobs which might alter system functionality.
+
+         If unsure, say N.
+

 config TEST_UDELAY
        tristate "udelay test driver"
        default n
 config TEST_UDELAY
        tristate "udelay test driver"
        default n


@@ -1825,6 +1875,33 @@ config BUG_ON_DATA_CORRUPTION
 
          If unsure, say N.
 
 
          If unsure, say N.
 

+config TEST_KMOD
+       tristate "kmod stress tester"
+       default n
+       depends on m
+       depends on BLOCK && (64BIT || LBDAF)      # for XFS, BTRFS
+       depends on NETDEVICES && NET_CORE && INET # for TUN
+       select TEST_LKM
+       select XFS_FS
+       select TUN
+       select BTRFS_FS
+       help
+         Test the kernel's module loading mechanism: kmod. kmod implements
+         support to load modules using the Linux kernel's usermode helper.
+         This test provides a series of tests against kmod.
+
+         Although technically you can either build test_kmod as a module or
+         into the kernel we disallow building it into the kernel since
+         it stress tests request_module() and this will very likely cause
+         some issues by taking over precious threads available from other
+         module load requests, ultimately this could be fatal.
+
+         To run tests run:
+
+         tools/testing/selftests/kmod/kmod.sh --help
+
+         If unsure, say N.
+

 source "samples/Kconfig"
 
 source "lib/Kconfig.kgdb"
 source "samples/Kconfig"
 
 source "lib/Kconfig.kgdb"