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] [day] [month] [year] [list]

Message-ID: <bc64b4640803081100i3872d699udfc64beb9d0e6@mail.gmail.com>
Date:	Sat, 8 Mar 2008 22:00:41 +0300
From:	Dmitry <dbaryshkov@...il.com>
To:	"Peter Zijlstra" <peterz@...radead.org>
Cc:	mingo@...hat.com, linux-kernel@...r.kernel.org
Subject: Re: Lockdep problem

Hi,

2008/3/8, Peter Zijlstra <peterz@...radead.org>:
>
>  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.

Unfortunately this happens before modules loading --- it's kernel itself.

>
>  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?

Actually no and yes. IIUC, the call chain looks like this (it's with
modified clk's functions, so
it may be a bit hard to understand. If you wish, search for "clocklib"
patches posted to LKML
nearly a month ago).
kernel -> clk_enable() takes global clock spinlock -> my function
which calls another spin_lock which causes lockdep warning.
If I disable global clocks spinlock locking, I get the lockdep
warning. Otherwise, I see no output. This seems to be related to the
fact that I have pxa serial console enabled which in turn also uses
clk_enable/clk_disable to manage its serial port.


>
>  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 :-)

I have a plenty of modules configured to build, but as I hope this
doesn't count, since they aren't loaded

-- 
With best wishes
Dmitry
--
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/