From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Thu, 24 May 2001 19:34:37 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Thu, 24 May 2001 19:34:27 -0400 Received: from ns.suse.de ([213.95.15.193]:6664 "HELO Cantor.suse.de") by vger.kernel.org with SMTP id ; Thu, 24 May 2001 19:34:09 -0400 Date: Fri, 25 May 2001 01:33:03 +0200 From: Andi Kleen To: Andreas Dilger Cc: linux-kernel@vger.kernel.org Subject: Re: [CHECKER] large stack variables (>=1K) in 2.4.4 and 2.4.4-ac8 Message-ID: <20010525013303.A21810@gruyere.muc.suse.de> In-Reply-To: <200105242110.OAA29766@csl.Stanford.EDU> <200105242308.f4ON8fv8015978@webber.adilger.int> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200105242308.f4ON8fv8015978@webber.adilger.int>; from adilger@turbolinux.com on Thu, May 24, 2001 at 05:08:40PM -0600 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 24, 2001 at 05:08:40PM -0600, Andreas Dilger wrote: > I'm curious about this stack checker. Does it check for a single > stack allocation >= 1024 bytes, or does it also check for several > individual, smaller allocations which total >= 1024 bytes inside > a single function? That would be equally useful. At one time someone had a script to grep objdump -S vmlinux for the stack allocations generated by gcc and check them. It found a few cases. It is easy to rewrite, as they are very regular instruction patterns at the beginning of functions (at least when you ignore variable length stack arrays, which do not seem to be common in the kernel anyways) > > On a side note, does anyone know if the kernel does checking if the > stack overflowed at any time? It is hard to use Dawson's tools to > verify call paths because of interrupts and such, but I wonder what > happens when the kernel stack overflows - OOPS, or silent corruption? You normally get a silent hang or worse a stack fault exception (which linux/x86 without kdb cannot recover from) which gives you instant reboot. The ikd patches contain a stack overflow checker for runtime. -Andi