From nobody Tue Apr 7 09:40:05 2026 Received: from mail-lf1-f49.google.com (mail-lf1-f49.google.com [209.85.167.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5C3233CA488 for ; Fri, 13 Mar 2026 17:12:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.167.49 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773421936; cv=none; b=Od1pgKi9mUCz9+av76zxSoohibTtaMWvNxcIrkb0a105Wp9w/ws95m0OAHKZ0VSuu8VIKewjJYvg06rWBdChU69rD1nNVPRTLNeMzOBlLYCPTJeKQdiOlNMxVLMrNgM21DCYwepxFAKykRVhDfUqbqxb+llyae1VOk3RKOXASMc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773421936; c=relaxed/simple; bh=OQYz4bAaA9YIwwq4U3ccuYAwXM8go1u3sUuEUi6Y9GA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=J9aqFQZeKGLfAsTQeg2cyUDXdGxNDtCRuRQIq366IjJQLKvB7o5jhiTN64AQkaAVWs7oCT7XHY3Ndqyfepavx29gvNRx4ZivPdUmaMs5U0hXhIHYbLtno+nsKeN3lV7JVyspmBtAzVGO+hvyqxk3UfkX6rPwW6CykSwFPQWwVCY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=cf9lhwN+; arc=none smtp.client-ip=209.85.167.49 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="cf9lhwN+" Received: by mail-lf1-f49.google.com with SMTP id 2adb3069b0e04-5a0ff30b240so3129848e87.0 for ; Fri, 13 Mar 2026 10:12:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773421933; x=1774026733; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=vvGS5QG3k/YrG1DdRI5ddkZ+WL5mhFkKeyfL1y9FIEY=; b=cf9lhwN+2GRWNc9rQOA1105Q77UfZQcMR6dh76SebrZGzoOHpyLev6ie2oVBR89soE pjMIVO5JG4h1jn8W3llQrk3FV569kRHXOOe5TpCpCMH0zfFvIhSGJue6k3cDhssK/4H/ TPbx6VjyUbQ3YJ/W+G5hadyaY39+X1OXOiiWOCLD+wMMUv71e9lME0n37W8z/ircx/i5 ICRw75OBw+W1hVmZu+PqeVQoUzfogExI9f3mwF5OA5FKNDjHnORkTFOToohqEYeHJ72f NzV2fWVYOohHJFFayXwayq+UTf5DIN+CyxS3r+mhDfPrgTFCukGkJhr7CxPL9fRSY2nE MFzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773421933; x=1774026733; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=vvGS5QG3k/YrG1DdRI5ddkZ+WL5mhFkKeyfL1y9FIEY=; b=hldWsrVkjYhffmgBet6ik18qTLDblxOTeA/ZC/mggPe5zET/Uad2yw6jMSf4fNRmGY X4GRlAZz5bClZNOIdoRfIEFYwT9f7acIQNdYoa93QocFOyTlr+d8brYAjsgoCnJD3ydJ DT2j43HDHBaAF0SEA+RBJmMK8DtO8Hs52QY67drFN67/Wx1j4WaD1QQADx+QkFuZmFMr Jd2CGRTjbaWLB+1UwcilZQFHlNrBb/sqSatDZLR69+vFF0Fqwxc3jlVzBSRSvnu4CWVV hofiXHBpAWKDyz27T39cJzmZRWeIzR3NJhKA1+FCsqZCacDxd7QIyRXqqXYltw3cTpbE 4rUg== X-Forwarded-Encrypted: i=1; AJvYcCUYx9mr02oLmd6lB4HaBBfJwjY08cp/CWoNZQ57Aa09RbGuoeVI1iTMw49CU8YkB3HXaE+ebThvCgmLHrM=@vger.kernel.org X-Gm-Message-State: AOJu0YxexIxZRqMv33dO9yDxCs+a32AhwnnpW6L7WsrW/v8Irn43J8VN 7E8IAy666iwlPfvcemtQaadDDbCLaLzlI3+cEr8NpmSKrGEHmNb/ObiS X-Gm-Gg: ATEYQzwGplAWMPYc80HmNpRDHtsegn5lRzxAoNztY36rQ3R6Ai10fDV82Af0EnMYt/J ldKxHZnGaFzxw5FBBnELa3SA+tRPPsKSH9V/xa3FAWFjV4PslKZK9l6oFzwCKVRQe3Jg0PZ/62W 8Fq/7ljBOlEuC7qJCu1EJPr4e7qMVyzj4jgVqy+tYE5UHfgBLuvUDLsguyUBl3ngOgegi6J2CaE /hdBOYwZHIMfkTkbf285valhtKsZTVwBVHoiW+/PwkQcbxGuGunbloyiJ6jUFrdwKekFDR+JKeP 8mhBZmmAhVvnlNyNwPgrG84siIXY4/hZxdmCp4c92AqpcJVYQu1E0sQ7XGN+POQQK45Yf8q4EOZ 0rJljikLfCuyK5mvb3VCEZMw1Ko248rTyu97WHnzrpBsCxinyzoNj47jOpt4xOgPCCc/3wV43uS iGTuBmMai65x/iR/M2dt8j9AffwskVm2KbLw== X-Received: by 2002:a05:6512:63c7:20b0:5a1:42b4:88c1 with SMTP id 2adb3069b0e04-5a1626fddc5mr1038612e87.12.1773421933174; Fri, 13 Mar 2026 10:12:13 -0700 (PDT) Received: from localhost ([188.234.148.119]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5a155f33cbesm1656550e87.9.2026.03.13.10.12.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 13 Mar 2026 10:12:12 -0700 (PDT) From: Mikhail Gavrilov To: Peter Zijlstra , Ingo Molnar Cc: Andrew Morton , Waiman Long , Bart Van Assche , Tetsuo Handa , Andrey Konovalov , Marco Elver , Boqun Feng , kasan-dev@googlegroups.com, linux-kernel@vger.kernel.org, Mikhail Gavrilov Subject: [PATCH RFC 1/1] lockdep: Raise default stack trace limits when KASAN is enabled Date: Fri, 13 Mar 2026 22:10:02 +0500 Message-ID: <20260313171118.1702954-2-mikhail.v.gavrilov@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260313171118.1702954-1-mikhail.v.gavrilov@gmail.com> References: <20260313171118.1702954-1-mikhail.v.gavrilov@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" 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 --- lib/Kconfig.debug | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index 93f356d2b3d9..813654204563 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -1618,14 +1618,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. =20 + 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. --=20 2.53.0