Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Thu, 27 Dec 2001 07:25:54 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Thu, 27 Dec 2001 07:25:43 -0500 Received: from h55p103-3.delphi.afb.lu.se ([130.235.187.176]:3738 "EHLO gin") by vger.kernel.org with ESMTP id ; Thu, 27 Dec 2001 07:25:30 -0500 Date: Thu, 27 Dec 2001 13:25:20 +0100 To: Andrew Morton Cc: andersg@0x63.nu, linux-kernel@vger.kernel.org, lvm-devel@sistina.com Subject: Re: lvm in 2.5.1 Message-ID: <20011227122520.GA2194@h55p111.delphi.afb.lu.se> In-Reply-To: <20011227084304.GA26255@h55p111.delphi.afb.lu.se> <3C2AEADB.24BEFE94@zip.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C2AEADB.24BEFE94@zip.com.au> User-Agent: Mutt/1.3.24i From: andersg@0x63.nu Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Dec 27, 2001 at 01:33:15AM -0800, Andrew Morton wrote: > > I'm now running 2.5.1 with lvm. The following patch makes some minor changes > > for bio-support and removes allocation of a lv_t on the stack, which made > > the stack overflow and gave me something to spend my last 24 hours > > debugging. > > That's a worry, because an lv_t is only 420 bytes. If that's triggering > a stack overflow then we're way too close. Think interrupts.... > > There must be other sources of stack bloat. > > lvm_chr_ioctl() calls lvm_do_vg_create(), and it has has another lv_t > on the stack. That's 840 bytes - still not enough. Maybe lvm_do_vg_create() > is calling something which uses lots of stack? Can't see it. Odd. did a calltrace in lvm_do_vg_create and it contains 48 symbols between Trace; c013c786 and Trace; c01a78f8 which looks like they comes from an old system call as it just contiains lots of unrelated symbols. That would suggest that lvm_char_ioctl allcates a big object on the stack that it havn't touched? Removing these symbols makes the calltrace look like: >>EIP; c01a8cf2 <===== Trace; c01a78f8 Trace; c013c786 Trace; c010856a not many symbols that could allcate stackspace, lets have a look how they allocates: 0x938 : sub $0x8,%esp not much... lets have a look at lvm_do_vg_create then: with my patch: 0x1830 : sub $0x20,%esp without my patch: 0x1830 : sub $0x11c4,%esp whoa! 0x11c4 thats a LOT! much more than sizeof(lv_t) > Seems that in various places here you've forgotten to free the lv_t storage > on error paths? of course, how could i forget.. will put together a new patch with that fixed in a minute. -- //anders/g - 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/