From 891626973b2faf468565a253ca55373e0b9675de Mon Sep 17 00:00:00 2001 From: Mikhail Gavrilov Date: Fri, 13 Mar 2026 22:10:02 +0500 Subject: 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 --- lib/Kconfig.debug | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'lib') diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index 4e2dfbbd3d78..e51e3c5a6538 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. -- cgit v1.2.3 From a21c1e961de28b95099a9ca2c3774b2eee1a33bb Mon Sep 17 00:00:00 2001 From: Marco Elver Date: Thu, 19 Mar 2026 14:52:38 +0100 Subject: compiler: Simplify generic RELOC_HIDE() When enabling Context Analysis (CONTEXT_ANALYSIS := y) in arch/x86/kvm code, Clang's Thread Safety Analysis failed to recognize that identical per_cpu() accesses refer to the same lock: | CC [M] arch/x86/kvm/vmx/posted_intr.o | arch/x86/kvm/vmx/posted_intr.c:186:2: error: releasing raw_spinlock '__ptr + __per_cpu_offset[vcpu->cpu]' that was not held [-Werror,-Wthread-safety-analysis] | 186 | raw_spin_unlock(&per_cpu(wakeup_vcpus_on_cpu_lock, vcpu->cpu)); | | ^ | ./include/linux/spinlock.h:276:32: note: expanded from macro 'raw_spin_unlock' | 276 | #define raw_spin_unlock(lock) _raw_spin_unlock(lock) | | ^ | arch/x86/kvm/vmx/posted_intr.c:207:1: error: raw_spinlock '__ptr + __per_cpu_offset[vcpu->cpu]' is still held at the end of function [-Werror,-Wthread-safety-analysis] | 207 | } | | ^ | arch/x86/kvm/vmx/posted_intr.c:182:2: note: raw_spinlock acquired here | 182 | raw_spin_lock_nested(&per_cpu(wakeup_vcpus_on_cpu_lock, vcpu->cpu), | | ^ | ./include/linux/spinlock.h:235:2: note: expanded from macro 'raw_spin_lock_nested' | 235 | _raw_spin_lock(((void)(subclass), (lock))) | | ^ | 2 errors generated. This occurred because the default RELOC_HIDE() implementation (used by the per-CPU macros) is a statement expression containing an intermediate 'unsigned long' variable (this version appears to predate Git history). While the analysis strips away inner casts when resolving pointer aliases, it stops when encountering intermediate non-pointer variables (this is Thread Safety Analysis specific and irrelevant for codegen). This prevents the analysis from concluding that the pointers passed to e.g. raw_spin_lock() and raw_spin_unlock() were identical when per-CPU accessors are used. Simplify RELOC_HIDE() to a single expression. This preserves the intent of obfuscating UB-introducing out-of-bounds pointer calculations from the compiler via the 'unsigned long' cast, but allows the alias analysis to successfully resolve the pointers. Using a recent Clang version, I observe that generated code remains the same for vmlinux; the intermediate variable was already being optimized away (for any respectable modern compiler, not doing so would be an optimizer bug). Note that GCC provides its own version of RELOC_HIDE(), so this change only affects Clang builds. Add a test case to lib/test_context-analysis.c to catch any regressions. Reported-by: Bart Van Assche Reported-by: Sean Christopherson Signed-off-by: Marco Elver Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Nathan Chancellor Link: https://lore.kernel.org/all/e3946223-4543-4a76-a328-9c6865e95192@acm.org/ Link: https://patch.msgid.link/20260319135245.1420780-1-elver@google.com --- lib/test_context-analysis.c | 11 +++++++++++ 1 file changed, 11 insertions(+) (limited to 'lib') diff --git a/lib/test_context-analysis.c b/lib/test_context-analysis.c index 140efa8a9763..06b4a6a028e0 100644 --- a/lib/test_context-analysis.c +++ b/lib/test_context-analysis.c @@ -596,3 +596,14 @@ static void __used test_ww_mutex_lock_ctx(struct test_ww_mutex_data *d) ww_mutex_destroy(&d->mtx); } + +static DEFINE_PER_CPU(raw_spinlock_t, test_per_cpu_lock); + +static void __used test_per_cpu(int cpu) +{ + raw_spin_lock(&per_cpu(test_per_cpu_lock, cpu)); + raw_spin_unlock(&per_cpu(test_per_cpu_lock, cpu)); + + raw_spin_lock(per_cpu_ptr(&test_per_cpu_lock, cpu)); + raw_spin_unlock(per_cpu_ptr(&test_per_cpu_lock, cpu)); +} -- cgit v1.2.3