linux-kernel - Re: [PATCH][RFC] 4K stacks default, not a debug thing any more...?

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: <46994BE3.7010608@gmail.com>
Date:	Sun, 15 Jul 2007 00:19:15 +0200
From:	Rene Herman <rene.herman@...il.com>
To:	Matt Mackall <mpm@...enic.com>
CC:	Jeremy Fitzhardinge <jeremy@...p.org>,
	Jesper Juhl <jesper.juhl@...il.com>,
	Ray Lee <ray-lk@...rabbit.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	William Lee Irwin III <wli@...omorphy.com>,
	David Chinner <dgc@....com>
Subject: Re: [PATCH][RFC] 4K stacks default, not a debug thing any more...?

On 07/14/2007 09:17 PM, Matt Mackall wrote:

> On Fri, Jul 13, 2007 at 03:20:54PM +0200, Rene Herman wrote:

>> As far as I'm aware, the actual reason for 4K stacks is that after the 
>> system has been up and running for some time getting "1 physically 
>> contiguous pages" becomes significantly easier than 2 which wouldn't be 
>> arbitrary.
> 
> If there are exactly two free pages in the system, the odds of them
> being buddies (ie adjacent AND properly aligned) is quite small. The
> available page pool has to grow quite a bit before the availability of
> order-1 page pairs approaches 100%. 
> 
> So if we fail to allocate an 8k stack when we could have allocated a
> 4k stack, we're almost certainly failing significantly prematurely.

Quite. Ofcourse, saying "our stacks are 1 page" would be the by far easiest 
solution to that. Personally, I've been running with 4K stacks exclusively 
on a variety of machines for quite some time now, but I can't say I'm all 
too adventurous with respect to filesystems (especially) so I'm not sure how 
many problems remain with 4K stacks. I did recently see Andrew Morton say 
that problems _do_ still exist. If it's just XFS -- well, heck...

Moreover though, rather than 4K, the issue is "single page" stacks meaning a 
larger (soft-) pagesize would seem to fix things nicely. I've been reading 
about that on this list off and on for some time -- no idea where that 
stands though.

> As I've pointed out before, it's fairly easy to make our stack
> growable with a trampoline in the troublesome paths. Something like:
> 
> int growstack(int headroom, int func, void *data)
> {
> 	void *new_stack;
> 	int ret;
> 
> 	if (likely(available_stack() > headroom))
> 		return func(data);
> 
> #ifdef CONFIG_GROWSTACK_STATS
> 	/* gather statistics about stack-heavy paths */
> #endif
> 	/* warn/abort if we're recursing too deeply */
> 
> 	new_stack = get_free_page();
> 	switch_to_new_stack(new_stack);
> 	ret = func(data);
> 	cleanup_stack(new_stack);
> 	return ret;
> }

This would also need something to tell func() where its current_thread_info 
  is now at. Which might not be much of a problem. Can't think of much else 
either but it's the kind of thing you'd _like_ to be a problem just to have 
an excuse to shoot down an icky notion like that...

Would you intend this just as a "make this path work until we fix it 
properly" kind of thing?

Rene.

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