Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754789AbXEAQuy (ORCPT ); Tue, 1 May 2007 12:50:54 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754792AbXEAQux (ORCPT ); Tue, 1 May 2007 12:50:53 -0400 Received: from agminet01.oracle.com ([141.146.126.228]:18830 "EHLO agminet01.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754789AbXEAQux (ORCPT ); Tue, 1 May 2007 12:50:53 -0400 Date: Tue, 1 May 2007 09:47:02 -0700 From: Bill Irwin To: Chuck Ebbert Cc: Bill Irwin , linux-kernel@vger.kernel.org, bunk@stusta.de, akpm@osdl.org, gcoady@gmail.com, zlynx@acm.org, dgc@sgi.com, alan@lxorguk.ukuu.org.uk, andi@firstfloor.org, hch@infradead.org, jengelh@linux01.gwdg.de, zwane@infradead.org, neilb@suse.de, jens.axboe@oracle.com, eric@provenscaling.com, wli@holomorphy.com Subject: Re: [3/3] use vmalloc() to arrange guard pages for stacks Message-ID: <20070501164702.GN26598@holomorphy.com> Mail-Followup-To: Bill Irwin , Chuck Ebbert , linux-kernel@vger.kernel.org, bunk@stusta.de, akpm@osdl.org, gcoady@gmail.com, zlynx@acm.org, dgc@sgi.com, alan@lxorguk.ukuu.org.uk, andi@firstfloor.org, hch@infradead.org, jengelh@linux01.gwdg.de, zwane@infradead.org, neilb@suse.de, jens.axboe@oracle.com, eric@provenscaling.com References: <20070430232351.GG26598@holomorphy.com> <20070430233309.GH26598@holomorphy.com> <20070430233712.GI26598@holomorphy.com> <20070430234030.GJ26598@holomorphy.com> <463757A3.7010808@redhat.com> <20070501163140.GM26598@holomorphy.com> <46376D97.3040603@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46376D97.3040603@redhat.com> User-Agent: Mutt/1.5.11 X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1298 Lines: 26 Bill Irwin wrote: >> It's a shame that the resource scalability implications of vmallocspace >> allocations prevent this from being useful in production. One could, in >> principle, establish guard pages within ZONE_NORMAL, but for 4KB stacks >> it's somewhat awkward to dredge up 3 contigous pages, and 4 defeats the >> purpose. Alignment with 8KB stacks wants 2 contiguous order 1 pages that >> span an order 2 page boundary. I guess I could rewrite the page allocator >> (again), but people seem to feel safest with the buddy allocator affairs. >> BTW, did the original patches for this prove to be of any use to you? On Tue, May 01, 2007 at 12:40:55PM -0400, Chuck Ebbert wrote: > No, I never tried them. Seems like I never get to anything these days but > answering bug reports and merging fixes... Putting the feature in-kernel > means I might get to use it though. :) Maybe it's a bit late for whatever bug you were hunting, but at least it'll help smoke out whatever other stack overflows you or anyone else might end up chasing down. -- wli - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/