From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f42.google.com (mail-wm1-f42.google.com [209.85.128.42]) (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 7E06C41D12A for ; Tue, 4 Aug 2026 07:15:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.42 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785827745; cv=none; b=KQqVSQDs8DahoznnVAAGZl6OJKWb3JYxyUJdi5bXkBXgyVPTg2juLsgVNL+l74O3IWhjZ8vQVS4AfT3QIc8hQdgcFTsUUIMNaxkG2f9LXBJt4gSM3KtFLBwwllrwZtM4X9LxHXSWzQsZkHSGMouNXylR9ps3dYxUDOCUutPJu4M= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785827745; c=relaxed/simple; bh=KFTvofAOXc5KmxmCdTNDIytUjcQ4KOu0Ww69ynrQf00=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=qe92Qqz/V6ROZujyU8TfCxGzqPapOCNin9rPABThn2VRy7Gc0tEQRWRZPGj1CvUA0Z4N3MPiguMC8l2J525/NwW+boYVinPbKsOxD8DjJCxwsuPV07e8Q64K0909LFDTp0x21XjkC6SAouEVXx4UXyGDGTHoGWw1YWLrPU0J430= 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=gbYzUpbw; arc=none smtp.client-ip=209.85.128.42 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="gbYzUpbw" Received: by mail-wm1-f42.google.com with SMTP id 5b1f17b1804b1-49554ebb87dso24577765e9.3 for ; Tue, 04 Aug 2026 00:15:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785827742; x=1786432542; 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=+G7ZNInz9uOgjQ51oO8dqIU6hAZbIrMARTqbNWdcA9c=; b=gbYzUpbw8JS8U6FNn87QYpi4eSGpN9l8WCp71UuPbRugjRx3TJW7mgyNuei6EHOiXD aHrkgLKTLsiyOJvDTD5XtEplhw8HLKW253h4UVe/YtN5YfoR+DRWy9FJoTHHcOkQgt9I 8Vu6+T+djlzc0h/V7e0TsmhyUI3YkxcER1M8qgA54CURtl1CD8ABPvXXzfbIGlrCBway EVFZKXHIfavH3zN/f3uhtPkuvf+RcJzQ0SMggCuWtCK36Z4uVXGngX/TItL6y2stfNH/ txQlyl8DIGkhoEMvDU5U+kbKyWnKU4FG6ELOLKyw6aGsduiaUjSFfq4YkeqKlgFETrsn D1qQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785827742; x=1786432542; 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=+G7ZNInz9uOgjQ51oO8dqIU6hAZbIrMARTqbNWdcA9c=; b=B6L31QYsF7ehhSAxqkHkF1CzcWhkLBN3rAhwjKedjYNmVQeG3XFJe2Fn8piET2if4Q mYzEEIogAML97UGNN1SUqIKjvi3CnIe44IlLYZCYh8kzgwQD+SfuwJrioQ+EomkYXv2A rFHgs3RVwPXAIqt2bsRhwHnBga/rL9UkS4k+r86mgptg2yXQVH7iQAQoIw4vBOPe70O1 55cAN4H4plugEnN15/uIR5PDB+bk+cBn0V9fNeT8mNrTaIF7JQYiYek2DhdV4ysFXlxi gOpk8KZ9Gc587wafKN7xhmRICnx0sDjalc5fWM0NR/FImD43ozDg41KawxZEDpKHDzwk cRKw== X-Forwarded-Encrypted: i=1; AHgh+RpGQVF9aV5n6YON7Kxay/lwHabHMkaUpPE99jPzzgHdGUi5T6VmDgBxKIOJLRCZGjrUmtw0XXNfaVxFxlQ=@vger.kernel.org X-Gm-Message-State: AOJu0YzMAJ2EKotspqsHk/OODi/Imr3QtIJs2TU2vrKPqoLa56MBktd2 SkwH9mCctuAH8nk8TIlatrEhF9ZBNB9pO2FFvPbQRIPP5WDQ+p7ahpML X-Gm-Gg: AR+sD12qAEtFblBjE5bkJJHGSHdpahxj1sK7dDER1vX9/23c0Zv3R1of0czJhiEGEGw /k/Y8EiHDc8lyjK+Y1pwkm/DzvlLIoyGZPaJ6c+Gq1z2MLu0h+T111iBtr4V45GeP5SZ3BPwUGl 70EE8v2vAuazwEs+IT1SdIAQhO/00cN0qd7Xvp/9aGmKrn+OKDKpLUor6FRtSHeFHzvsXTTNJSF xFtuBRgZguF2wKCvYtu5m63UKWdsexLu6IkiRmp6YYONDyoBybgbYMIehrDFAViWNLC2dZNEFpW bB9dtkFA3nO6mgdavO+NjRKdpJ04QG5dKASAmb0CsF4wHPjVnbfv8awQhB6DUoxOsvdKIf6K7eN D+6bY6wNGglbD74phfmEkNRFMkTl5upupw2O5UXOKAFNlQuLJu+J3WWqY0WkmMLrfawCg+lCTHz 8gdsfad3N0rsDOaQnwX0Gq8Kw2R23aukopN5rkKAkBInRVNuw1qPWMpqzVulQXlKqEf/ZjVNDQw 5LHsxs7I7QCfDfyabOga42tuzCWd5ArIneqAcI6Wg== X-Received: by 2002:a05:600c:8b17:b0:495:4491:b8c2 with SMTP id 5b1f17b1804b1-4980c66c926mr286212955e9.3.1785827741454; Tue, 04 Aug 2026 00:15:41 -0700 (PDT) Received: from fedora ([202.47.63.86]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49807b6093fsm179634045e9.1.2026.08.04.00.15.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 04 Aug 2026 00:15:40 -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, zhanxusheng1024@gmail.com, linux-kernel@vger.kernel.org, Muhammad Bilal Subject: [PATCH v2] locking/lockdep: make chain-hlocks average depth configurable Date: Tue, 4 Aug 2026 12:15:29 +0500 Message-ID: <20260804071529.216920-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. struct lock_chain::base is a 24-bit index into chain_hlocks[], and add_chain_cache() enforces that with: BUILD_BUG_ON((1UL << 24) <= ARRAY_SIZE(chain_hlocks)); so MAX_LOCKDEP_CHAINS * LOCKDEP_CHAIN_DEPTH must stay under 2^24 for every reachable combination, not just the default. LOCKDEP_CHAINS_BITS goes up to 21, so the new knob's range is capped at 7 -- one more than that would let 2^21 * 8 == 2^24 reach the limit and fail the build at the top of the CHAINS_BITS range. The help text explains the cap instead of pointing people at a combination that can break the build. Reported-by: Zhan Xusheng Signed-off-by: Muhammad Bilal --- kernel/locking/lockdep_internals.h | 2 +- lib/Kconfig.debug | 25 +++++++++++++++++++++++++ 2 files changed, 26 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..723df2bf8c5d 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -1614,6 +1614,31 @@ 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 7 + 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. + + The upper bound of 7 is not arbitrary: struct lock_chain::base is + a 24-bit index into chain_hlocks[], and add_chain_cache() has + BUILD_BUG_ON((1UL << 24) <= ARRAY_SIZE(chain_hlocks)). At the + maximum LOCKDEP_CHAINS_BITS of 21, a depth of 8 or higher makes + MAX_LOCKDEP_CHAIN_HLOCKS reach 2^24 and fails the build, so the + range here is capped to stay safe for every valid + LOCKDEP_CHAINS_BITS setting rather than just the default. + 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