Re: [PATCH] locking/lockdep: make chain-hlocks average depth configurable

[Zhan Xusheng]

From: Zhan Xusheng <zhanxusheng1024@xxxxxxxxx>

On Tue, Aug 04, 2026 at 02:50:40AM +0500, Muhammad Bilal wrote:
> +	range 3 20
[...]
> +	   Increase this value if you hit that message and LOCKDEP_CHAINS_BITS
> +	   increases alone don't help.

I might be missing something, but doesn't the top of this range interact
with LOCKDEP_CHAINS_BITS in a way that can fail the build?

MAX_LOCKDEP_CHAIN_HLOCKS is (1 << LOCKDEP_CHAINS_BITS) * LOCKDEP_CHAIN_DEPTH,
and add_chain_cache() has:

	BUILD_BUG_ON((1UL << 24) <= ARRAY_SIZE(chain_hlocks));

since lock_chain.base is a 24-bit index into chain_hlocks[]. So the product
has to stay below 2^24.

LOCKDEP_CHAINS_BITS ranges up to 21, so with the new knob:

	CHAINS_BITS=21, DEPTH=8  ->  2^21 * 8 == 2^24  ->  BUILD_BUG_ON fires

i.e. at the maximum CHAINS_BITS anything above DEPTH=7 stops building. Today,
with the fixed depth of 5, 2^21 * 5 stays under the limit, so this is a new
combination the patch makes reachable.

What I find a little awkward is that this is exactly the path the help text
points people at: someone who already raised LOCKDEP_CHAINS_BITS to 21
chasing the "too low" message and then bumps LOCKDEP_CHAIN_DEPTH as suggested
gets a (fairly opaque) BUILD_BUG_ON rather than a larger pool.

Kconfig can't easily express the (1 << CHAINS_BITS) * DEPTH < 2^24 product,
so would it make sense to at least spell the constraint out in the help text
and note that the build fails otherwise? Capping the range for the worst case
(CHAINS_BITS=21 => DEPTH <= 7) would be safe but would needlessly restrict the
common CHAINS_BITS=16 case, where much larger depths are fine.

Thanks,
Zhan Xusheng