Re: lvm in 2.5.1

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 <sys_ioctl+16a/184>

and 

Trace; c01a78f8 <lvm_chr_ioctl+2b8/670>

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 <lvm_do_vg_create+22/498>   <=====
Trace; c01a78f8 <lvm_chr_ioctl+2b8/670>
Trace; c013c786 <sys_ioctl+16a/184>
Trace; c010856a <system_call+32/38>

not many symbols that could allcate stackspace, lets have a look how they
allocates:

0x938 <lvm_blk_ioctl>:		   sub    $0x8,%esp

not much... lets have a look at lvm_do_vg_create then:

with my patch:
0x1830 <lvm_do_vg_create>:	   sub    $0x20,%esp

without my patch:
0x1830 <lvm_do_vg_create>:	   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