linux-kernel - Re: Lockdep problem

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: <1204997457.6241.314.camel@lappy>
Date:	Sat, 08 Mar 2008 18:30:57 +0100
From:	Peter Zijlstra <peterz@...radead.org>
To:	Dmitry <dbaryshkov@...il.com>
Cc:	mingo@...hat.com, linux-kernel@...r.kernel.org
Subject: Re: Lockdep problem

On Sat, 2008-03-08 at 20:10 +0300, Dmitry wrote:
> Hi,
> 
> I've ran into the lockdep problem: I'm hitting the condition at the
> lockdep.c:2437:
>        if (DEBUG_LOCKS_WARN_ON(id >= MAX_LOCKDEP_KEYS))
>                 return 0;
> 
> What does it mean and how to overcome it? Dumbly increasing constants
> at kernel/lockdep_internals.h didn't help.

It means you have more lockdep classes (lock instantiation sites,
explicit class keys etc..) that we have static storage reserved for.

One way to quickly achieve this is load/unload modules. Zapping the
classes on module unload does not make the space available again.

Sadly most setups these days try to load every module under the sun,
wasting valuable boot time, and causing this head-ache.

Someone reported to me increasing MAX_LOCKDEP_KEYS_BITS to 15 (IIRC)
made his distro build work again. Of course, cycle reloading a module
will eventually run you out of space anyway.

> The warning is pretty fatal for me because it happens when I'm locking
> clocks lock, so when serial console output calls
> clk_enable/clk_disable the kernel deadlocks.

Not sure I fully understand what you mean here, but I've never seen this
result in anything but a warning, the kernel will just continue..

Or are you trying to debug a deadlock and can't because lockdep runs out
of classes before it gets to the offending code?

Something you can do is build a kernel without (or very few modules) - a
good idea anyway as turning off all that unused stuff will significantly
improve build times too :-)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/