From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f49.google.com (mail-wr1-f49.google.com [209.85.221.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 425561A9FB0 for ; Mon, 3 Aug 2026 21:50:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.49 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785793854; cv=none; b=qMXTz0tAMVU8QOZXX+x8ekk0uH01kP1w8sPgDgGr4wEkts0eaQU9ioBbHZQXFJMGyWhDdTfzfiQGo/FqRdM8D15ORhMlzSfLRj4M3CelHnZsN6XLJOjy97vuIZgLfun7I+l0AeXj7LNZLM8OlApo+lTz07PJARd4e+jC+VQGqq0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785793854; c=relaxed/simple; bh=srOUK+TZrq9FtfCJp/goc5zVIkLCamfChvQsE7+UnT8=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=Oir0ixfgVvfv7VrZh4J19S2HkrJt+7piQJdcpdWrWFiMhNn8AZb90PI23OhQWjc0Lvw/MzlSpueulcqyqqD3edMJ2n7HV0bTmI/6fnfyBCbKDi5D9ZBDjSrV3jZDJ7hWTC1W8onMlejqqKDeSVcNiaQt7DmpMWs38PvMS5MG3Is= 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=nA31hp5+; arc=none smtp.client-ip=209.85.221.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="nA31hp5+" Received: by mail-wr1-f49.google.com with SMTP id ffacd0b85a97d-47f7854678cso1934400f8f.1 for ; Mon, 03 Aug 2026 14:50:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785793851; x=1786398651; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to:content-type; bh=rBoJvWEUtJU9VpcspAtq0EQPVIU30Diiu79pg8iv1L4=; b=nA31hp5+g1u47zOATHjJMHaz/+mf4NqKHTwkNCfBhBYizWfk2i0nv/plw/kqomNvlL q9q7dyCZQ/56ktJpT8z9hZayDJRMCURHoxR1WNKqWL9RBsIOUBIZI59/I4a5QMtH9hnO t4oKeY2wwBcOD6xBraqv90qFkl6ELqgUKVSHLeYPZrD0p+8deyKZe/Xa0DwjMDBgDmnw Q+FO5ZYuABcanRRDOFkEF1c8R+YPrnSbIfYmGH2+f+2vVvCmFviFOqteWY6/lyaQdE8w CxAqz0V2f96saKZsoBl3UnsNN91tYDRVmkp2qTi3KU2ulKnBvUSYanWawJQwBzdnKA1o ARIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785793851; x=1786398651; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=rBoJvWEUtJU9VpcspAtq0EQPVIU30Diiu79pg8iv1L4=; b=NKTLsaWYyBbbfQTE3JM8ZjvyarRuqlJpqcncYN+UxL28SOjFOOZmeDUP2XWhHOv4iL MvBQi6x07m+Uz4olmEV72AYh8+s5OcBeA6lIHNFqjs5VfuR/z9TeP9Gd8K7Jsoqsl8kK 4KulbG2y6pZX27ov1duYGNn/gYqlkLfxat1/O0M0aJFVUwUytkzT6wgFnkxJZ5zI0fLj XV21vj6C/hsYLie2Sq+y8J5NWXxORvkZ+v9eHafnzNCr4H0/fClljCqLOJw0pTadj8Xd f2RfP26xPAw7tTI/3/+5OWbBKha0n8hTF0H4u9kzLjPY0HH7A2fKWXhounn4RkdUYcHU yw8A== X-Forwarded-Encrypted: i=1; AHgh+Rr4sQEnxv1a5szYRf8+tSj3cx8pwIWTdGZiR392YD1To/C8N89M8TY/WYrD5XthQrhGTbGfcglNHqpKlcc=@vger.kernel.org X-Gm-Message-State: AOJu0Yw/LzqOTd5e9dnbxLXY6NSiB3EHV+Za8DNJSo6QbW728PeGehvM izqvLjAsjnDwxRwJcghFYNDAwfy0gfHnlxBj3mdk2Nz0BO8ct/bJPqst X-Gm-Gg: AR+sD115hwHFdbxaKuNFJFB095JRtuJ0IedL3a/HRWQB3SvOP3pSwg+ARUD8/q4QWcA cK/iV+3J0X4fM6ACn3aST7a96SxRGrhVnQ3PP/W6noI6HybRTc2I+7GgTDf9KNCARVlphhbfI+H 5sZVTvmZmQfiIZei2PWmHvIMieBE5gLdnN03WfqzZ5XGyegy6marsSJzOSCgjJPP1ZQ7EU+ZUhM ucnP9fOYK1HiPdKsAHccP7qdXCel433MZXBazQCIXyeNp/PK6ctEjpiAJvT2lmKIe+fSy+sXkav rE1AN8k4mIpj7VcoE0ETrwLRJSppqL7I9cMKpWRp4Z1fpayrmbzj3royLWBTajx6uYl8E19xbmI z5Pd84yZODprAt++skt3vl2ivQQ5YNg2BdHEyvZKhQ43RxAwyX/si3f6vMx3HPSQnE2PrMOnAdk nLstLguR98B/jmpeZOKwCEyNzOrqWNjiHAU4QIBtvOLMLc5mVRxOOvj/rxIH1WW9J6aSLHpq9d9 JWIZ+YQ8hEGXRaq/QkGTxvNQABkfeITMPJH04YRkQ== X-Received: by 2002:adf:ec49:0:b0:47e:12d9:1c79 with SMTP id ffacd0b85a97d-47fd72b3649mr24780587f8f.27.1785793851501; Mon, 03 Aug 2026 14:50:51 -0700 (PDT) Received: from fedora ([202.47.63.86]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-47fd41e2cf1sm36795436f8f.10.2026.08.03.14.50.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 03 Aug 2026 14:50:50 -0700 (PDT) From: Muhammad Bilal To: peterz@infradead.org, mingo@redhat.com, will@kernel.org, boqun@kernel.org Cc: longman@redhat.com, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, Muhammad Bilal Subject: [PATCH] locking/lockdep: make chain-hlocks average depth configurable Date: Tue, 4 Aug 2026 02:50:40 +0500 Message-ID: <20260803215040.172457-1-meatuni001@gmail.com> X-Mailer: git-send-email 2.55.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit The static chain_hlocks[] pool is sized as: MAX_LOCKDEP_CHAIN_HLOCKS = MAX_LOCKDEP_CHAINS * AVG_LOCKDEP_CHAIN_DEPTH MAX_LOCKDEP_CHAINS is already tunable via CONFIG_LOCKDEP_CHAINS_BITS, but AVG_LOCKDEP_CHAIN_DEPTH is hardcoded to 5 and has no Kconfig knob. Workloads that build unusually deep individual lock chains -- rather than simply a large number of distinct chains -- can exhaust chain_hlocks[] and trip: BUG: MAX_LOCKDEP_CHAIN_HLOCKS too low! well before MAX_LOCKDEP_CHAINS itself is anywhere near full, which silently disables lock debugging for the rest of the boot (debug_locks_off_graph_unlock()). Bumping LOCKDEP_CHAINS_BITS alone does not help in that case since the bottleneck is chain depth, not chain count. Observed on a PREEMPT_DYNAMIC + RCU lockdep + KASAN debug build, reproducing at every boot from add_chain_cache() failing to allocate out of the static pool, hit from sched wakeup, hrtimer, and btrfs flush-workqueue paths (deep IRQ/softirq nesting stacked on top of deep filesystem/scheduler call chains). Add CONFIG_LOCKDEP_CHAIN_DEPTH so this can be tuned like LOCKDEP_BITS/LOCKDEP_CHAINS_BITS, defaulting to 5 to preserve current behavior for everyone who isn't hitting this. Signed-off-by: Muhammad Bilal --- kernel/locking/lockdep_internals.h | 2 +- lib/Kconfig.debug | 17 +++++++++++++++++ 2 files changed, 18 insertions(+), 1 deletion(-) diff --git a/kernel/locking/lockdep_internals.h b/kernel/locking/lockdep_internals.h index 0e5e6ffe91a3..ed566681f3c8 100644 --- a/kernel/locking/lockdep_internals.h +++ b/kernel/locking/lockdep_internals.h @@ -121,7 +121,7 @@ enum { #define MAX_LOCKDEP_CHAINS (1UL << MAX_LOCKDEP_CHAINS_BITS) -#define AVG_LOCKDEP_CHAIN_DEPTH 5 +#define AVG_LOCKDEP_CHAIN_DEPTH CONFIG_LOCKDEP_CHAIN_DEPTH #define MAX_LOCKDEP_CHAIN_HLOCKS (MAX_LOCKDEP_CHAINS * AVG_LOCKDEP_CHAIN_DEPTH) extern struct lock_chain lock_chains[]; diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index 1244dcac2294..90b7f990611d 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -1614,6 +1614,23 @@ config LOCKDEP_CHAINS_BITS help Try increasing this value if you hit "BUG: MAX_LOCKDEP_CHAINS too low!" message. +config LOCKDEP_CHAIN_DEPTH + int "Average depth for MAX_LOCKDEP_CHAIN_HLOCKS" + depends on LOCKDEP + range 3 20 + default 5 + help + Average per-chain depth used to size the static chain_hlocks[] + pool: MAX_LOCKDEP_CHAIN_HLOCKS = MAX_LOCKDEP_CHAINS * + LOCKDEP_CHAIN_DEPTH. + + Workloads that build unusually deep lock chains (heavy irq/softirq + nesting stacked on top of deep filesystem or scheduler call chains) + can exhaust this pool and trip "BUG: MAX_LOCKDEP_CHAIN_HLOCKS too + low!" well before MAX_LOCKDEP_CHAINS itself is exhausted, silently + disabling lock debugging. Increase this value if you hit that + message and LOCKDEP_CHAINS_BITS increases alone don't help. + config LOCKDEP_STACK_TRACE_BITS int "Size for MAX_STACK_TRACE_ENTRIES (as Nth power of 2)" depends on LOCKDEP && !LOCKDEP_SMALL -- 2.55.0