linux-kernel - Re: x86: 4kstacks default

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: <20080420142056.GC26536@1wt.eu>
Date:	Sun, 20 Apr 2008 16:20:56 +0200
From:	Willy Tarreau <w@....eu>
To:	Eric Sandeen <sandeen@...deen.net>
Cc:	Mark Lord <lkml@....ca>, Andi Kleen <andi@...stfloor.org>,
	Adrian Bunk <bunk@...nel.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Shawn Bohrer <shawn.bohrer@...il.com>,
	Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Arjan van de Ven <arjan@...radead.org>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: x86: 4kstacks default

On Sun, Apr 20, 2008 at 09:09:37AM -0500, Eric Sandeen wrote:
> Mark Lord wrote:
> > Willy Tarreau wrote:
> >> What would really help would be to have 8k stacks with the lower page
> >> causing a fault and print a stack trace upon first access. That way,
> >> the safe setting would still report us useful information without
> >> putting users into trouble.
> > ..
> > 
> > That's the best suggestion from this thread, by far!
> > Can you produce a patch for 2.6.26 for this?
> > Or perhaps someone else here, with the right code familiarity, could?
> > 
> > Some sort of CONFIG option would likely be wanted to
> > either enable/disable this feature, of course.
> 
> Changing the default warning threshold is easy, it's just a #define.

I thought it was checked only at a few places (eg: during irqs). If so,
maybe it can miss some call chains ?

> Although setting it too low would spam syslogs on some setups.

we should set it slightly below the 4k limit if we want users to switch
to 4k.

> When I was trying to cram stuff into 4k in the past, I had a patch which
> added a sysctl to dynamically change the warning threshold, and
> optionally BUG() when I hit it for crash analysis.  It was good for
> debugging, at least.  If something along those lines is desired, I could
> resurrect it.

While it's good for debugging, having users tweak the limit to eliminate
the warning is the opposite of what we're looking for. We just want to
have them report the warning without their service being disrupted.

Willy

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