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

Good catch! Just send v2 with fix.

Thanks,
Muhammad Bilal

On Tue, Aug 4, 2026 at 7:32 AM Zhan Xusheng <[email protected]> wrote:
>
> From: Zhan Xusheng <[email protected]>
>
> 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