Kernel checking options

[Sitsofe Wheeler]

With the recent drive for more testers I'm curious about options that can be
turned on that will do more checking/verification (as opposed to just
creating more debug output). 

Thus far I have come across the following that suggest that they will do
extra checks:

CONFIG_DEBUG_SHIRQ:
Tests whether drivers can handle spurious interrupts upon registration /
unregistration.

CONFIG_DETECT_SOFTLOCKUP:
Detects if the kernel spends more than 10 seconds in the kernel without
giving anything else a chance to run and prints a stacktrace.

CONFIG_DEBUG_OBJECTS:
Tracks the lifetime of various objects (what does this mean?) and validates
operations on those objects.

CONFIG_DEBUG_OBJECTS_SELFTEST:
Runs a self test on the object debug code.

CONFIG_DEBUG_OBJECTS_FREE:
Detects and reports whether memory freed with kmalloc / vmalloc still
contains an object that hasn't been properly deactivated.

CONFIG_DEBUG_OBJECTS_TIMERS:
Tracks the lifetime of timer objects (what does this mean?) and validates
timer operations.

CONFIG_SLUB_DEBUG_ON:
Boot with SLUB debugging on by default. Detects and reports when slub
objects have become corrupt. Can create guard zones around objects and
poison objects not currently in use.

CONFIG_DEBUG_RT_MUTEXES:
Detects and reports realtime mutex semantic violoations realtime mutex
related deadlocks.

CONFIG_DEBUG_SPINLOCK:
Detects missing spinlock initialisation and other common spinlock errors.
May need to be used with an NMI watchdog.

CONFIG_DEBUG_MUTEXES:
Detects and reports mutex semantics violations.

CONFIG_DEBUG_LOCK_ALLOC:
Detects and reports whether a held {spinlock, rwlock, mutex, rwsem} is being
incorrectly freed when memory is freed, whether a live lock is being
incorrectly reinitialised, or if a lock is still being held when a task
exits.

CONFIG_PROVE_LOCKING:
Detects and reports if a particular sequence of locks could lead to a
deadlock.

CONFIG_DEBUG_LOCKDEP:
Do checks on the lock dependency engine.

CONFIG_DEBUG_SPINLOCK_SLEEP:
Certain routines (that can sleep) will be detected and reported if called
while a spinlock is held.

CONFIG_DEBUG_HIGHMEM:
Does additional error checking for high (1GByte or greater) memory systems.

CONFIG_DEBUG_VM:
Does extended checks on the virtual-memory system.

CONFIG_DEBUG_WRITECOUNT:
Detects and reports incorrect use of the writers count in struct vfsmount.

CONFIG_DEBUG_LIST:
Does extended checks on linked list walking routines.

CONFIG_DEBUG_SG:
Does checks on scatter-gather tables.

CONFIG_KERNEL_TESTS:
This enables the ability to select additional tests.

CONFIG_DEBUG_LOCKING_API_SELFTESTS:
Runs a self test on the lock dependency engine.

CONFIG_RT_MUTEX_TESTER:
Enables a rt-mutex tester.

CONFIG_BACKTRACE_SELF_TEST:
Runs a self test on the backtrace code.

CONFIG_DEBUG_STACKOVERFLOW:
Detects and reports if the free stack space drops below a certain threshold.

CONFIG_DEBUG_PAGEALLOC:
Unmaps pages from the kernel linear mapping after free_pages() is called.

CONFIG_DEBUG_RODATA:
Marks kernel read only data as write protected. 

CONFIG_DEBUG_RODATA_TEST:
Runs a self test on the RODATA feature.

CONFIG_CPA_DEBUG:
Does a change_page_attr() self-test every 30 seconds.

CONFIG_X86_MCE:
Detect and reports if the hardware notices an anomaly in itself.

CONFIG_MAC80211_DEBUG_PACKET_ALIGNMENT:
Detects and warns if a driver hands mac80211 a buffer that is aligned in
that could cause a problem with the IP stack on some architectures.

CONFIG_SND_DEBUG:
Enable the ability to select ALSA debug code?

CONFIG_SND_PCM_XRUN_DEBUG:
Detects and reports PCM ring buffer overruns/underruns (e.g. due to
scheduling gaps).

Is this list complete? Are they all enabling additional checks?

Additionally are there any options that will make (real) bugs more likely to
occur? For example does preemption make bugs related to races (that could
happen without preemption) happen more often?

-- 
Sitsofe | http://sucs.org/~sits/

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/