Since the x86 defconfig aims to be a distro kernel work-alike with
fewer drivers and a shorter build time, enable a handful of
kernel debugging options that are typically enabled on major Linux
distributions.

The options enabled is a superset of the latest Ubuntu and Fedora
kernel debugging configs, using Ubuntu's config-6.11.0-24-generic
file, Fedora's kernel-x86_64-fedora.config and RHEL's
kernel-x86_64-rhel.config from kernel-ark.git.

Notable features enabled:

 - CONFIG_UBSAN=y:

     Despite the runtime overhead, UBSAN is actively enabled
     in all 3 major Linux distros I checked, so we want it
     enabled in the defconfig as well - to better see the
     consequences.

 - CONFIG_DEBUG_SHIRQ=y:

     Fedora/RHEL have this enabled, while Ubuntu has it disabled.

 - CONFIG_DEBUG_LIST=y:

     Fedora/RHEL have it enabled, while Ubuntu has it disabled.

 - CONFIG_FUNCTION_PROFILER=y:

     This is enabled on all distros I checked as well.

DEBUGINFO is still disabled, despite enabled in all Linux distros,
because the ~10x .o bloat is still just so painful on anything
but the most powerful build boxes.

Note that while the following features seemingly get removed from
the defconfig :

  - CONFIG_BLK_DEV_INITRD=y
  - CONFIG_KPROBES=y
  - CONFIG_MAGIC_SYSRQ=y

they are actually still enabled in the actual .config, because they
get selected by other options indirectly.

Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: David Woodhouse <dwmw@amazon.co.uk>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Michal Marek <michal.lkml@markovi.net>
---
 arch/x86/configs/defconfig.x86_64 | 46 ++++++++++++++++++++++++++++++++++++---
 1 file changed, 43 insertions(+), 3 deletions(-)

diff --git a/arch/x86/configs/defconfig.x86_64 b/arch/x86/configs/defconfig.x86_64
index 4f2fab465196..3d585c33016b 100644
--- a/arch/x86/configs/defconfig.x86_64
+++ b/arch/x86/configs/defconfig.x86_64
@@ -31,7 +31,6 @@ CONFIG_CGROUP_PERF=y
 CONFIG_CGROUP_BPF=y
 CONFIG_CGROUP_MISC=y
 CONFIG_CGROUP_DEBUG=y
-CONFIG_BLK_DEV_INITRD=y
 CONFIG_KALLSYMS_ALL=y
 CONFIG_PROFILING=y
 CONFIG_KEXEC=y
@@ -69,7 +68,6 @@ CONFIG_KVM_INTEL=y
 CONFIG_KVM_AMD=y
 CONFIG_KVM_XEN=y
 CONFIG_KVM_MAX_NR_VCPUS=4096
-CONFIG_KPROBES=y
 CONFIG_JUMP_LABEL=y
 CONFIG_MODULES=y
 CONFIG_MODULE_UNLOAD=y
@@ -298,13 +296,55 @@ CONFIG_SECURITY_NETWORK=y
 CONFIG_SECURITY_SELINUX=y
 CONFIG_SECURITY_SELINUX_BOOTPARAM=y
 CONFIG_PRINTK_TIME=y
+CONFIG_BOOT_PRINTK_DELAY=y
+CONFIG_DYNAMIC_DEBUG=y
 CONFIG_DEBUG_KERNEL=y
-CONFIG_MAGIC_SYSRQ=y
+CONFIG_STRIP_ASM_SYMS=y
+CONFIG_HEADERS_INSTALL=y
+CONFIG_DEBUG_SECTION_MISMATCH=y
+CONFIG_KGDB=y
+CONFIG_KGDB_TESTS=y
+CONFIG_KGDB_LOW_LEVEL_TRAP=y
+CONFIG_KGDB_KDB=y
+CONFIG_KDB_KEYBOARD=y
+CONFIG_UBSAN=y
+CONFIG_UBSAN_SHIFT=y
+CONFIG_PAGE_OWNER=y
+CONFIG_PAGE_POISONING=y
 CONFIG_DEBUG_WX=y
+CONFIG_PER_VMA_LOCK_STATS=y
 CONFIG_DEBUG_STACK_USAGE=y
+CONFIG_SCHED_STACK_END_CHECK=y
+CONFIG_KFENCE=y
+CONFIG_DEBUG_SHIRQ=y
+CONFIG_PANIC_ON_OOPS=y
+CONFIG_HARDLOCKUP_DETECTOR=y
+CONFIG_BOOTPARAM_HARDLOCKUP_PANIC=y
+CONFIG_WQ_CPU_INTENSIVE_REPORT=y
 CONFIG_SCHEDSTATS=y
+CONFIG_NMI_CHECK_CPU=y
+CONFIG_DEBUG_LIST=y
+CONFIG_RCU_CPU_STALL_CPUTIME=y
+CONFIG_BOOTTIME_TRACING=y
+CONFIG_FUNCTION_GRAPH_RETVAL=y
+CONFIG_FPROBE=y
+CONFIG_FUNCTION_PROFILER=y
+CONFIG_STACK_TRACER=y
+CONFIG_SCHED_TRACER=y
+CONFIG_HWLAT_TRACER=y
+CONFIG_TIMERLAT_TRACER=y
+CONFIG_MMIOTRACE=y
+CONFIG_FTRACE_SYSCALLS=y
 CONFIG_BLK_DEV_IO_TRACE=y
+CONFIG_USER_EVENTS=y
+CONFIG_HIST_TRIGGERS=y
+CONFIG_TRACE_EVENT_INJECT=y
+CONFIG_RV=y
+CONFIG_RV_MON_WWNR=y
 CONFIG_PROVIDE_OHCI1394_DMA_INIT=y
 CONFIG_EARLY_PRINTK_DBGP=y
+CONFIG_EARLY_PRINTK_USB_XDBC=y
 CONFIG_DEBUG_BOOT_PARAMS=y
 CONFIG_DEBUG_ENTRY=y
+CONFIG_FUNCTION_ERROR_INJECTION=y
+CONFIG_MEMTEST=y
-- 
2.45.2

On 2025-05-05 at 13:09 +0200, Ingo Molnar wrote:
> 
>  - CONFIG_DEBUG_LIST=y:
> 
>      Fedora/RHEL have it enabled, while Ubuntu has it disabled.

(Please forgive my potential ignorance.)

If I'm guessing right, the point of CONFIG_DEBUG_LIST being enabled
everywhere is probably more about hardening than debugging, and given
that since 6.6 we have a CONFIG_LIST_HARDENED[1], wouldn't it make more
sense to use that instead?

Or is the point here to exactly follow the typical distro config,
without regard to whether it's actually the optimal thing to do?

[1]: https://lore.kernel.org/all/20230811151847.1594958-3-elver@google.com/

-- 
Ivan Shapovalov / intelfx /

* Ivan Shapovalov <intelfx@intelfx.name> wrote:

> On 2025-05-05 at 13:09 +0200, Ingo Molnar wrote:
> > 
> >  - CONFIG_DEBUG_LIST=y:
> > 
> >      Fedora/RHEL have it enabled, while Ubuntu has it disabled.
> 
> (Please forgive my potential ignorance.)
> 
> If I'm guessing right, the point of CONFIG_DEBUG_LIST being enabled
> everywhere is probably more about hardening than debugging, and given
> that since 6.6 we have a CONFIG_LIST_HARDENED[1], wouldn't it make more
> sense to use that instead?

Yeah, I agree, and I've just changed it to CONFIG_LIST_HARDENED=y, 
which I agree is the more sensible default.

> Or is the point here to exactly follow the typical distro config,
> without regard to whether it's actually the optimal thing to do?
> 
> [1]: https://lore.kernel.org/all/20230811151847.1594958-3-elver@google.com/

So Ubuntu doesn't have it:

  /boot/config-6.11.0-25-generic:# CONFIG_LIST_HARDENED is not set

While Fedora has it:

  .config.fedora.generic:CONFIG_LIST_HARDENED=y

in which case it's basically a judgement call whether to do it in the 
defconfig. I agree that DEBUG_LIST=y is pretty heavy-handed, 
LIST_HARDENED=y looks better to me.

But when all major distros have an option enabled then I think in most 
cases the right policy is to enable it in our defconfig as well, 
because the option has become ubiquitous and we'd be denying reality by 
not having it in our regular tests.

Thanks,

	Ingo

> DEBUGINFO is still disabled, despite enabled in all Linux distros,
> because the ~10x .o bloat is still just so painful on anything
> but the most powerful build boxes.

My hope is that soon, we'll be in a position to have directly-generated
BTF (which should be far quicker than generating tonnes of DWARF) which
should resolve that.