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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 21 Apr 2008 21:51:02 +0200
From:	Denys Vlasenko <vda.linux@...glemail.com>
To:	Eric Sandeen <sandeen@...deen.net>
Cc:	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 Monday 21 April 2008 15:29, Eric Sandeen wrote:
> > Some number has to be picked. Why fitting in 4k is "bad" and fitting
> > in 8k is "not bad"?
> 
> 
> Because well-written code in several subsystems, used in combination in
> common configurations, does not always fit, that is why.
> 
> Show me the "bug" in an nfs+xfs+md+scsi writeback stack oops

Why nfs+xfs+md+ide works? Does scsi intrinsically require more stack
than ide?

Why xfs code is said to be 5 timed bigged than e.g. reiserfs?
Does it have to be that big? Does it really have to eat lots of stack?

> and I'm 
> sure it'll get "fixed."  But if it's simply complex code that happens to
> need >4k, I will continue to argue that the limited stack size selection
> is the problem, not the code running in it.

8k stack is limited too. Other Operating System, no doubt in the name
of better stability, has even larger stack (16k or more).

For what its worth, I do realize that there is a point of diminishing
returns and increased pain when one tries to reduce stack usage.
I feel that 4k for 32-bit x86 is not too painful. IMO, of course.

> If someone has a workload and configuration which happens to fit in 4k
> then turn it on, test the heck out of it, and have fun.  I've not seen
> what I consider to be a convincing argument for making it the default
> for everyone.

Conversely:

"If someone is strongly concerned about possibility of stack overflow,
then turn on 8k option, and enjoy the benefits of wide testing which
is provided by millions of people who run 4k stacks. If _that_ works
ok in practice, 8k _ought_ to be 100.00% safe versus stack overflow".

These threads about 4k stack seem to degenerate in ping-ponging
of these arguments again and again.
--
vda
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ