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

Date:	Wed, 21 Apr 2010 07:53:01 -0700
From:	Sven-Thorsten Dietrich <thebigcorporation@...il.com>
To:	John Kacur <jkacur@...hat.com>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	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, 2010-04-21 at 14:12 +0200, John Kacur wrote:
> 
> 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.
> 

Working from ancient memory here:

I think that this is seen more on the distro side - had the same problem
with SLERT. 

And yes, it did show up more with additional debug options -- when
structs with #ifdef DEBUG_XXX are populated.

IIRC there is another caveat, if MAX_STACK_TRACE_ENTRIES is too large,
you run out of memory uncompressing the Kernel (on 32 bit only?) and it
hangs.

We put patches in place to manually increase to something workable, but
I would ACK this change, allowing tinkering.

Regards,

Sven

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