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
| ||
|
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/
Powered by blists - more mailing lists