bybrooklyn/linux
1
0
Fork 0
mirror of https://github.com/torvalds/linux.git synced 2026-04-18 14:53:58 -04:00
Code Issues Packages Projects Releases Wiki Activity

lockdep: Raise default stack trace limits when KASAN is enabled

Browse Source 
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 (12593b7467) 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 <mikhail.v.gavrilov@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://patch.msgid.link/20260313171118.1702954-2-mikhail.v.gavrilov@gmail.com
This commit is contained in:
Mikhail Gavrilov
2026-03-13 22:10:02 +05:00
committed by Peter Zijlstra
parent 2deccd5c86
commit 891626973b
1 changed files with 8 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
lib/Kconfig.debug
View File

@@ -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.