linux-kernel - Re: BUG: MAX_LOCKDEP_CHAIN

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250310112315.GS16878@noisy.programming.kicks-ass.net>
Date: Mon, 10 Mar 2025 12:23:15 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Mikhail Gavrilov <mikhail.v.gavrilov@...il.com>
Cc: Chris Murphy <lists@...orremedies.com>,
	Waiman Long <longman@...hat.com>, Boqun Feng <boqun.feng@...il.com>,
	David Sterba <dsterba@...e.cz>,
	Btrfs BTRFS <linux-btrfs@...r.kernel.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...hat.com>, Will Deacon <will@...nel.org>,
	Joel Fernandes <joel@...lfernandes.org>
Subject: Re: BUG: MAX_LOCKDEP_CHAIN_HLOCKS too low!

On Mon, Mar 10, 2025 at 03:51:21AM +0500, Mikhail Gavrilov wrote:
> On Fri, Jan 27, 2023 at 8:33 PM Chris Murphy <lists@...orremedies.com> wrote:
> > Also, at least in Fedora Rawhide where the mainline debug kernels appear, mostly get used non-interactively with automated tests. So if we're going to discover lockdep issues, we need the kernel logs to be reliable at the time those tests are run, and we don't have a practical way of adding another boot parameter just for these tests.
> >
> > Anyway I went ahead and submitted an MR to bump this to 19.
> > https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2271
> >
> 
> Hi,
> Two years have passed since my last message in this thread.
> And now CONFIG_LOCKDEP_CHAIN_BITS=19 has become insufficient.
> https://gitlab.com/cki-project/kernel-ark/-/blob/os-build/redhat/configs/fedora/generic/CONFIG_LOCKDEP_CHAINS_BITS
> 
> I am again faced by "BUG: MAX_LOCKDEP_CHAIN_HLOCKS too low!"
> Still not exists a boot parameter that could redefine
> MAX_LOCKDEP_CHAIN_HLOCKS at boot time?
> And what should we do? Again, bump CONFIG_LOCKDEP_CHAIN_BITS? Now up to 20?

What are you actually doing? Anyway, check your chains to see if there's
anything obviously silly causing a combinatorial explosion.