From: Mikhail Gavrilov Date: Fri, 13 Mar 2026 17:10:02 +0000 (+0500) Subject: lockdep: Raise default stack trace limits when KASAN is enabled X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=891626973b2faf468565a253ca55373e0b9675de;p=thirdparty%2Fkernel%2Flinux.git lockdep: Raise default stack trace limits when KASAN is enabled KASAN-enabled kernels with LOCKDEP and PREEMPT_FULL hit "BUG: MAX_STACK_TRACE_ENTRIES too low!" within 9-23 hours of normal desktop use. The root cause is a feedback loop between KASAN slab tracking and lockdep: every KASAN-tracked slab allocation saves a stack trace via stack_trace_save() -> arch_stack_walk(). The unwinder calls is_bpf_text_address(), which under PREEMPT_FULL can trigger RCU deferred quiescent-state processing -> swake_up_one() -> lock_acquire() -> lockdep validate_chain() -> save_trace(). This means KASAN's own stack captures indirectly generate new lockdep dependency chains, consuming the buffer from both directions. /proc/lockdep_stats at the moment of overflow confirms that stack-trace entries is the sole exhausted resource: stack-trace entries: 524288 [max: 524288] <- 100% full number of stack traces: 22080 <- unique after dedup dependency chains: 164665 [max: 524288] <- only 31% used direct dependencies: 45270 [max: 65536] <- 69% lock-classes: 2811 [max: 8192] <- 34% 22080 genuinely unique traces averaging ~24 frames each fill the buffer in under a day. The hash-based deduplication (12593b7467f9) is working correctly -- the traces are simply all different due to the deep and varied call stacks from GPU + filesystem + Wine/Proton + KASAN instrumentation. Raise the LOCKDEP_STACK_TRACE_BITS default from 19 to 21 when KASAN is enabled (2M entries, +12MB). This is negligible compared to KASAN's own shadow memory overhead (~12.5% of total RAM). Scale LOCKDEP_STACK_TRACE_HASH_BITS accordingly to maintain dedup efficiency. Signed-off-by: Mikhail Gavrilov Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20260313171118.1702954-2-mikhail.v.gavrilov@gmail.com --- diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index 4e2dfbbd3d786..e51e3c5a65381 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -1617,14 +1617,22 @@ config LOCKDEP_STACK_TRACE_BITS int "Size for MAX_STACK_TRACE_ENTRIES (as Nth power of 2)" depends on LOCKDEP && !LOCKDEP_SMALL range 10 26 + default 21 if KASAN default 19 help Try increasing this value if you hit "BUG: MAX_STACK_TRACE_ENTRIES too low!" message. + KASAN significantly increases stack trace consumption because its + slab tracking interacts with lockdep's dependency validation under + PREEMPT_FULL, creating a feedback loop. The higher default when + KASAN is enabled costs ~12MB extra, which is negligible compared to + KASAN's own shadow memory overhead. + config LOCKDEP_STACK_TRACE_HASH_BITS int "Size for STACK_TRACE_HASH_SIZE (as Nth power of 2)" depends on LOCKDEP && !LOCKDEP_SMALL range 10 26 + default 16 if KASAN default 14 help Try increasing this value if you need large STACK_TRACE_HASH_SIZE.