linux-kernel - Re: [PATCH v3] lockdep: Make MAX_STACK_TRACE

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: <alpine.LFD.2.00.1004211407510.4506@localhost.localdomain>
Date:	Wed, 21 Apr 2010 14:12:53 +0200 (CEST)
From:	John Kacur <jkacur@...hat.com>
To:	Peter Zijlstra <peterz@...radead.org>
cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>,
	linux-rt-users@...r.kernel.org,
	Thomas Gleixner <tglx@...utronix.de>,
	Clark Williams <williams@...hat.com>,
	"Luis Claudio R. Goncalves" <lgoncalv@...hat.com>,
	Gregory Haskins <ghaskins@...ell.com>
Subject: Re: [PATCH v3] lockdep: Make MAX_STACK_TRACE_ENTRIES configurable.



On Wed, 21 Apr 2010, Peter Zijlstra wrote:

> On Wed, 2010-04-21 at 13:12 +0200, John Kacur wrote:
> > 
> > Certain configurations that have LOCKDEP turned on, run into the limit
> > where the MAX_STACK_TRACE_ENTRIES are too small. Rather than simply
> > turning of the locking correctness validator let the user configure this
> > value to something reasonable for their system.
> 
> I'm not sure its worth having a CONFIG_ value for this, that'll just be
> yet another random value nobody knows what to do with.
> 
> Do you actually have a machine that reproduces this? Can you see how
> many classes, avg stacktraces per class and the avg entries per
> stacktrace there are?

This triggers every single time when I boot my T500 laptop with 
2.6.33.2-rt13 with lots of debug options enabled. The problem is not
specific to this kernel though.

> 
> Also, is there's lots of classes, are there many with a similar name?
> 
> That is, is it a valid depletion or is there something wonkey with those
> setups?

Here are the top 10 lines or so of /proc/lockdep_stats

 lock-classes:                         1330 [max: 8191]
 direct dependencies:                 12754 [max: 16384]
 indirect dependencies:               33245
 all direct dependencies:             49074
 dependency chains:                   19641 [max: 32768]
 dependency chain hlocks:             73246 [max: 163840]
 in-hardirq chains:                      25
 in-softirq chains:                       0
 in-process chains:                   19616
 stack-trace entries:                262144 [max: 262144]


I'm looking at more details in /proc/lockdep and friends to see if
I can find any more details, or something that looks amiss.

John
--
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/