[PATCH v2] configs: Introduce debug.config for CI-like setup

[PATCH v2] configs: Introduce debug.config for CI-like setup

[Qian Cai]

Some general debugging features like kmemleak, KASAN, lockdep, UBSAN etc
help fix many viruses like a microscope. On the other hand, those features
are scatter around and mixed up with more situational debugging options
making them difficult to consume properly. This cold help amplify the
general debugging/testing efforts and help establish sensitive default
values for those options across the broad.

The config is based on years' experiences running daily CI inside the
largest enterprise Linux distro company to seek regressions on
linux-next builds on different bare-metal and virtual platforms. This is
more of some art than science. It can be used for example,

$ make ARCH=arm64 defconfig debug.config

Signed-off-by: Qian Cai <quic_qiancai@quicinc.com>
---
v2:
Double the size of CONFIG_DEBUG_KMEMLEAK_MEM_POOL_SIZE due to the most
of defconfigs used 4KB page instead of 64KB which would consume more early
kmemleak objects to track early_pgtable_alloc(). Otherwise, we could
run out of kmemleak early memory pool and disable kmemleak entirely.

 kernel/configs/debug.config | 119 ++++++++++++++++++++++++++++++++++++
 1 file changed, 119 insertions(+)
 create mode 100644 kernel/configs/debug.config

diff --git a/kernel/configs/debug.config b/kernel/configs/debug.config
new file mode 100644
index 000000000000..fea127155eb6
--- /dev/null
+++ b/kernel/configs/debug.config
@@ -0,0 +1,119 @@
+# Keep alphabetically sorted.
+#
+# CONFIG_BOOTPARAM_HUNG_TASK_PANIC is not set
+# CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC is not set
+# CONFIG_DEBUG_KMEMLEAK_DEFAULT_OFF is not set
+# CONFIG_DEBUG_PAGEALLOC is not set
+# CONFIG_DEBUG_RODATA_TEST is not set
+# CONFIG_DEBUG_WX is not set
+# CONFIG_KFENCE is not set
+# CONFIG_PAGE_POISONING is not set
+# CONFIG_PROVE_RAW_LOCK_NESTING is not set
+# CONFIG_SLUB_STATS is not set
+# CONFIG_UBSAN_ALIGNMENT is not set
+# CONFIG_UBSAN_DIV_ZERO is not set
+# CONFIG_UBSAN_TRAP is not set
+# CONFIG_WARN_ALL_UNSEEDED_RANDOM is not set
+CONFIG_BRANCH_PROFILE_NONE=y
+CONFIG_BUG_ON_DATA_CORRUPTION=y
+CONFIG_CONTEXT_SWITCH_TRACER=y
+CONFIG_DEBUG_ATOMIC_SLEEP=y
+CONFIG_DEBUG_BUGVERBOSE=y
+CONFIG_DEBUG_FS_ALLOW_ALL=y
+CONFIG_DEBUG_FS=y
+CONFIG_DEBUG_INFO=y
+CONFIG_DEBUG_IRQFLAGS=y
+CONFIG_DEBUG_KERNEL=y
+CONFIG_DEBUG_KMEMLEAK_AUTO_SCAN=y
+CONFIG_DEBUG_KMEMLEAK_MEM_POOL_SIZE=80000
+CONFIG_DEBUG_KMEMLEAK=y
+CONFIG_DEBUG_LIST=y
+CONFIG_DEBUG_LOCK_ALLOC=y
+CONFIG_DEBUG_MUTEXES=y
+CONFIG_DEBUG_OBJECTS_ENABLE_DEFAULT=1
+CONFIG_DEBUG_OBJECTS_FREE=y
+CONFIG_DEBUG_OBJECTS_PERCPU_COUNTER=y
+CONFIG_DEBUG_OBJECTS_RCU_HEAD=y
+CONFIG_DEBUG_OBJECTS_TIMERS=y
+CONFIG_DEBUG_OBJECTS_WORK=y
+CONFIG_DEBUG_OBJECTS=y
+CONFIG_DEBUG_PER_CPU_MAPS=y
+CONFIG_DEBUG_RT_MUTEXES=y
+CONFIG_DEBUG_RWSEMS=y
+CONFIG_DEBUG_SECTION_MISMATCH=y
+CONFIG_DEBUG_SPINLOCK=y
+CONFIG_DEBUG_STACK_USAGE=y
+CONFIG_DEBUG_VIRTUAL=y
+CONFIG_DEBUG_VM_PGFLAGS=y
+CONFIG_DEBUG_VM_RB=y
+CONFIG_DEBUG_VM_VMACACHE=y
+CONFIG_DEBUG_VM=y
+CONFIG_DEBUG_WW_MUTEX_SLOWPATH=y
+CONFIG_DEFAULT_HUNG_TASK_TIMEOUT=120
+CONFIG_DETECT_HUNG_TASK=y
+CONFIG_DYNAMIC_DEBUG_CORE=y
+CONFIG_DYNAMIC_DEBUG=y
+CONFIG_DYNAMIC_FTRACE_WITH_REGS=y
+CONFIG_DYNAMIC_FTRACE=y
+CONFIG_EVENT_TRACING=y
+CONFIG_FRAME_POINTER=y
+CONFIG_FRAME_WARN=2048
+CONFIG_FTRACE_MCOUNT_RECORD=y
+CONFIG_FTRACE_MCOUNT_USE_PATCHABLE_FUNCTION_ENTRY=y
+CONFIG_FTRACE=y
+CONFIG_FUNCTION_TRACER=y
+CONFIG_GENERIC_PTDUMP=y
+CONFIG_GENERIC_TRACER=y
+CONFIG_IO_STRICT_DEVMEM=y
+CONFIG_KASAN_GENERIC=y
+CONFIG_KASAN_INLINE=y
+CONFIG_KASAN_STACK=y
+CONFIG_KASAN_VMALLOC=y
+CONFIG_KASAN=y
+CONFIG_LOCK_DEBUGGING_SUPPORT=y
+CONFIG_LOCKDEP_BITS=15
+CONFIG_LOCKDEP_CHAINS_BITS=16
+CONFIG_LOCKDEP_CIRCULAR_QUEUE_BITS=12
+CONFIG_LOCKDEP_STACK_TRACE_BITS=19
+CONFIG_LOCKDEP_STACK_TRACE_HASH_BITS=14
+CONFIG_LOCKDEP=y
+CONFIG_LOCKUP_DETECTOR=y
+CONFIG_MAGIC_SYSRQ_DEFAULT_ENABLE=0x1
+CONFIG_MAGIC_SYSRQ_SERIAL_SEQUENCE=""
+CONFIG_MAGIC_SYSRQ_SERIAL=y
+CONFIG_MAGIC_SYSRQ=y
+CONFIG_NOP_TRACER=y
+CONFIG_PAGE_EXTENSION=y
+CONFIG_PAGE_OWNER=y
+CONFIG_PANIC_ON_OOPS_VALUE=1
+CONFIG_PANIC_ON_OOPS=y
+CONFIG_PANIC_TIMEOUT=0
+CONFIG_PREEMPTIRQ_TRACEPOINTS=y
+CONFIG_PRINTK_CALLER=y
+CONFIG_PRINTK_TIME=y
+CONFIG_PROVE_LOCKING=y
+CONFIG_PROVE_RCU_LIST=y
+CONFIG_PROVE_RCU=y
+CONFIG_PTDUMP_CORE=y
+CONFIG_PTDUMP_DEBUGFS=y
+CONFIG_RCU_CPU_STALL_TIMEOUT=60
+CONFIG_RING_BUFFER=y
+CONFIG_SCHED_INFO=y
+CONFIG_SCHED_STACK_END_CHECK=y
+CONFIG_SECTION_MISMATCH_WARN_ONLY=y
+CONFIG_SLUB_DEBUG_ON=y
+CONFIG_SOFTLOCKUP_DETECTOR=y
+CONFIG_STACKTRACE=y
+CONFIG_STRICT_DEVMEM=y
+CONFIG_SYMBOLIC_ERRNAME=y
+CONFIG_TRACE_CLOCK=y
+CONFIG_TRACE_IRQFLAGS=y
+CONFIG_TRACING_SUPPORT=y
+CONFIG_TRACING=y
+CONFIG_UBSAN_BOOL=y
+CONFIG_UBSAN_BOUNDS=y
+CONFIG_UBSAN_ENUM=y
+CONFIG_UBSAN_ONLY_BOUNDS=y
+CONFIG_UBSAN_SHIFT=y
+CONFIG_UBSAN_UNREACHABLE=y
+CONFIG_UBSAN=y
-- 
2.30.2

Re: [PATCH v2] configs: Introduce debug.config for CI-like setup

[Daniel Thompson]

On Thu, Oct 28, 2021 at 11:44:34PM -0400, Qian Cai wrote:
> Some general debugging features like kmemleak, KASAN, lockdep, UBSAN etc
> help fix many viruses like a microscope. On the other hand, those features
> are scatter around and mixed up with more situational debugging options
> making them difficult to consume properly. This cold help amplify the
> general debugging/testing efforts and help establish sensitive default
> values for those options across the broad.
> 
> The config is based on years' experiences running daily CI inside the
> largest enterprise Linux distro company to seek regressions on
> linux-next builds on different bare-metal and virtual platforms. This is
> more of some art than science. It can be used for example,
> 
> $ make ARCH=arm64 defconfig debug.config
> 
> Signed-off-by: Qian Cai <quic_qiancai@quicinc.com>
> ---
> v2:
> Double the size of CONFIG_DEBUG_KMEMLEAK_MEM_POOL_SIZE due to the most
> of defconfigs used 4KB page instead of 64KB which would consume more early
> kmemleak objects to track early_pgtable_alloc(). Otherwise, we could
> run out of kmemleak early memory pool and disable kmemleak entirely.
> 
>  kernel/configs/debug.config | 119 ++++++++++++++++++++++++++++++++++++
>  1 file changed, 119 insertions(+)
>  create mode 100644 kernel/configs/debug.config
> 
> diff --git a/kernel/configs/debug.config b/kernel/configs/debug.config
> new file mode 100644
> index 000000000000..fea127155eb6
> --- /dev/null
> +++ b/kernel/configs/debug.config
> @@ -0,0 +1,119 @@

Does this config need comments at the top of the file describing its 
"mission"?  Put another way, the comments in the description about
where these config options come from seem too important leave buried
in the git history. They are important to understanding what it is
for.

I know this the other configs do not have big header comments. However
the existing configs are closer to self-describing. debug.config simply
does not explain what the file does in the way xen.config can! People
will surely want to add their "favourite" debug options[1] and those
contributors would benefit from clues on what the configs here are
intended for.


> +# Keep alphabetically sorted.

This results in 119 line file that is more-or-less impossible to
comment. It alphabetic really the best way to maintain something
containing so much subjective judgement?


Daniel.



> +#
> +# CONFIG_BOOTPARAM_HUNG_TASK_PANIC is not set
> +# CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC is not set
> +# CONFIG_DEBUG_KMEMLEAK_DEFAULT_OFF is not set
> +# CONFIG_DEBUG_PAGEALLOC is not set
> +# CONFIG_DEBUG_RODATA_TEST is not set
> +# CONFIG_DEBUG_WX is not set
> +# CONFIG_KFENCE is not set
> +# CONFIG_PAGE_POISONING is not set
> +# CONFIG_PROVE_RAW_LOCK_NESTING is not set
> +# CONFIG_SLUB_STATS is not set
> +# CONFIG_UBSAN_ALIGNMENT is not set
> +# CONFIG_UBSAN_DIV_ZERO is not set
> +# CONFIG_UBSAN_TRAP is not set
> +# CONFIG_WARN_ALL_UNSEEDED_RANDOM is not set
> +CONFIG_BRANCH_PROFILE_NONE=y
> +CONFIG_BUG_ON_DATA_CORRUPTION=y
> +CONFIG_CONTEXT_SWITCH_TRACER=y
> +CONFIG_DEBUG_ATOMIC_SLEEP=y
> +CONFIG_DEBUG_BUGVERBOSE=y
> +CONFIG_DEBUG_FS_ALLOW_ALL=y
> +CONFIG_DEBUG_FS=y
> +CONFIG_DEBUG_INFO=y
> +CONFIG_DEBUG_IRQFLAGS=y
> +CONFIG_DEBUG_KERNEL=y
> +CONFIG_DEBUG_KMEMLEAK_AUTO_SCAN=y
> +CONFIG_DEBUG_KMEMLEAK_MEM_POOL_SIZE=80000
> +CONFIG_DEBUG_KMEMLEAK=y
> +CONFIG_DEBUG_LIST=y
> +CONFIG_DEBUG_LOCK_ALLOC=y
> +CONFIG_DEBUG_MUTEXES=y
> +CONFIG_DEBUG_OBJECTS_ENABLE_DEFAULT=1
> +CONFIG_DEBUG_OBJECTS_FREE=y
> +CONFIG_DEBUG_OBJECTS_PERCPU_COUNTER=y
> +CONFIG_DEBUG_OBJECTS_RCU_HEAD=y
> +CONFIG_DEBUG_OBJECTS_TIMERS=y
> +CONFIG_DEBUG_OBJECTS_WORK=y
> +CONFIG_DEBUG_OBJECTS=y
> +CONFIG_DEBUG_PER_CPU_MAPS=y
> +CONFIG_DEBUG_RT_MUTEXES=y
> +CONFIG_DEBUG_RWSEMS=y
> +CONFIG_DEBUG_SECTION_MISMATCH=y
> +CONFIG_DEBUG_SPINLOCK=y
> +CONFIG_DEBUG_STACK_USAGE=y
> +CONFIG_DEBUG_VIRTUAL=y
> +CONFIG_DEBUG_VM_PGFLAGS=y
> +CONFIG_DEBUG_VM_RB=y
> +CONFIG_DEBUG_VM_VMACACHE=y
> +CONFIG_DEBUG_VM=y
> +CONFIG_DEBUG_WW_MUTEX_SLOWPATH=y
> +CONFIG_DEFAULT_HUNG_TASK_TIMEOUT=120
> +CONFIG_DETECT_HUNG_TASK=y
> +CONFIG_DYNAMIC_DEBUG_CORE=y
> +CONFIG_DYNAMIC_DEBUG=y
> +CONFIG_DYNAMIC_FTRACE_WITH_REGS=y
> +CONFIG_DYNAMIC_FTRACE=y
> +CONFIG_EVENT_TRACING=y
> +CONFIG_FRAME_POINTER=y
> +CONFIG_FRAME_WARN=2048
> +CONFIG_FTRACE_MCOUNT_RECORD=y
> +CONFIG_FTRACE_MCOUNT_USE_PATCHABLE_FUNCTION_ENTRY=y
> +CONFIG_FTRACE=y
> +CONFIG_FUNCTION_TRACER=y
> +CONFIG_GENERIC_PTDUMP=y
> +CONFIG_GENERIC_TRACER=y
> +CONFIG_IO_STRICT_DEVMEM=y
> +CONFIG_KASAN_GENERIC=y
> +CONFIG_KASAN_INLINE=y
> +CONFIG_KASAN_STACK=y
> +CONFIG_KASAN_VMALLOC=y
> +CONFIG_KASAN=y
> +CONFIG_LOCK_DEBUGGING_SUPPORT=y
> +CONFIG_LOCKDEP_BITS=15
> +CONFIG_LOCKDEP_CHAINS_BITS=16
> +CONFIG_LOCKDEP_CIRCULAR_QUEUE_BITS=12
> +CONFIG_LOCKDEP_STACK_TRACE_BITS=19
> +CONFIG_LOCKDEP_STACK_TRACE_HASH_BITS=14
> +CONFIG_LOCKDEP=y
> +CONFIG_LOCKUP_DETECTOR=y
> +CONFIG_MAGIC_SYSRQ_DEFAULT_ENABLE=0x1
> +CONFIG_MAGIC_SYSRQ_SERIAL_SEQUENCE=""
> +CONFIG_MAGIC_SYSRQ_SERIAL=y
> +CONFIG_MAGIC_SYSRQ=y
> +CONFIG_NOP_TRACER=y
> +CONFIG_PAGE_EXTENSION=y
> +CONFIG_PAGE_OWNER=y
> +CONFIG_PANIC_ON_OOPS_VALUE=1
> +CONFIG_PANIC_ON_OOPS=y
> +CONFIG_PANIC_TIMEOUT=0
> +CONFIG_PREEMPTIRQ_TRACEPOINTS=y
> +CONFIG_PRINTK_CALLER=y
> +CONFIG_PRINTK_TIME=y
> +CONFIG_PROVE_LOCKING=y
> +CONFIG_PROVE_RCU_LIST=y
> +CONFIG_PROVE_RCU=y
> +CONFIG_PTDUMP_CORE=y
> +CONFIG_PTDUMP_DEBUGFS=y
> +CONFIG_RCU_CPU_STALL_TIMEOUT=60
> +CONFIG_RING_BUFFER=y
> +CONFIG_SCHED_INFO=y
> +CONFIG_SCHED_STACK_END_CHECK=y
> +CONFIG_SECTION_MISMATCH_WARN_ONLY=y
> +CONFIG_SLUB_DEBUG_ON=y
> +CONFIG_SOFTLOCKUP_DETECTOR=y
> +CONFIG_STACKTRACE=y
> +CONFIG_STRICT_DEVMEM=y
> +CONFIG_SYMBOLIC_ERRNAME=y
> +CONFIG_TRACE_CLOCK=y
> +CONFIG_TRACE_IRQFLAGS=y
> +CONFIG_TRACING_SUPPORT=y
> +CONFIG_TRACING=y
> +CONFIG_UBSAN_BOOL=y
> +CONFIG_UBSAN_BOUNDS=y
> +CONFIG_UBSAN_ENUM=y
> +CONFIG_UBSAN_ONLY_BOUNDS=y
> +CONFIG_UBSAN_SHIFT=y
> +CONFIG_UBSAN_UNREACHABLE=y
> +CONFIG_UBSAN=y
> -- 
> 2.30.2
> 

Re: [PATCH v2] configs: Introduce debug.config for CI-like setup

[Qian Cai]

On 10/29/21 5:31 AM, Daniel Thompson wrote:
> Does this config need comments at the top of the file describing its 
> "mission"?  Put another way, the comments in the description about
> where these config options come from seem too important leave buried
> in the git history. They are important to understanding what it is
> for.
> 
> I know this the other configs do not have big header comments. However
> the existing configs are closer to self-describing. debug.config simply
> does not explain what the file does in the way xen.config can! People
> will surely want to add their "favourite" debug options[1] and those
> contributors would benefit from clues on what the configs here are
> intended for.

Daniel, (small world, isn't it? Enjoyed your OpenEmbedded lessons in the
past.), That's a good point. I personally got used to "git log". I'll
add some comments there.

>> +# Keep alphabetically sorted.
> 
> This results in 119 line file that is more-or-less impossible to
> comment. It alphabetic really the best way to maintain something
> containing so much subjective judgement?

I thought about ordering those in different subject groups, but then
realized it might be an overkill for an only one-hundred line file. Most
of the options would have a prefix like _LOCKDEP_, _KMEMLEAK_ etc, so
they are subject-related close together even sorted alphabetically. I
don't really have a strong option on this matter though. We could
organize it like in Kconfig sections if people like that way better
although it could have a potential overhead to sync with future
Kconfig.debug in the future as their places and names change from time
to time.

# printk and dmesg options
# Compile-time checks and compiler options
# Generic Kernel Debugging Instruments
# Memory Debugging
# Scheduler Debugging
# Lock Debugging (spinlocks, mutexes, etc...)
# Debug kernel data structures
# RCU Debugging

Re: [PATCH v2] configs: Introduce debug.config for CI-like setup

[Daniel Thompson]

On Fri, Oct 29, 2021 at 09:57:31AM -0400, Qian Cai wrote:
> On 10/29/21 5:31 AM, Daniel Thompson wrote:
> > Does this config need comments at the top of the file describing its 
> > "mission"?  Put another way, the comments in the description about
> > where these config options come from seem too important leave buried
> > in the git history. They are important to understanding what it is
> > for.
> > 
> > I know this the other configs do not have big header comments. However
> > the existing configs are closer to self-describing. debug.config simply does not explain what the file does in the way xen.config can! People
> > will surely want to add their "favourite" debug options[1] and those
> > contributors would benefit from clues on what the configs here are
> > intended for.
> 
> Daniel, (small world, isn't it? Enjoyed your OpenEmbedded lessons in the
> past.), That's a good point. I personally got used to "git log". I'll
> add some comments there.

Hello again.

In this case the small world comes about because "debug" is of the
keywords I use to filter LKML ;-)


> >> +# Keep alphabetically sorted.
> > 
> > This results in 119 line file that is more-or-less impossible to
> > comment. It alphabetic really the best way to maintain something
> > containing so much subjective judgement?
> 
> I thought about ordering those in different subject groups, but then
> realized it might be an overkill for an only one-hundred line file. Most
> of the options would have a prefix like _LOCKDEP_, _KMEMLEAK_ etc, so
> they are subject-related close together even sorted alphabetically.

My feedback came about because, in alphabetic form, it is not easy to
see which ftrace tracers are enabled (because they are named
CONFIG_<feature>_TRACER they appear all over the place).


> I don't really have a strong option on this matter though. We could
> organize it like in Kconfig sections if people like that way better
> although it could have a potential overhead to sync with future
> Kconfig.debug in the future as their places and names change from time
> to time.
> 
> # printk and dmesg options
> # Compile-time checks and compiler options
> # Generic Kernel Debugging Instruments
> # Memory Debugging
> # Scheduler Debugging
> # Lock Debugging (spinlocks, mutexes, etc...)
> # Debug kernel data structures
> # RCU Debugging

Personally I'd favour this. It really depends on how often it is
read/changed by uesrs rather than just consumed by the build system.
Personally I think this will be read quite often.


Daniel.

Re: [PATCH v2] configs: Introduce debug.config for CI-like setup

[Qian Cai]

On 10/29/21 12:19 PM, Daniel Thompson wrote:
> My feedback came about because, in alphabetic form, it is not easy to
> see which ftrace tracers are enabled (because they are named
> CONFIG_<feature>_TRACER they appear all over the place).

Good point, Daniel. I also think the existing categories could change
but are fairly stable. I'll reorganize them.