Re: [CHECKER] large stack variables (>=1K) in 2.4.4 and 2.4.4-ac8

[Andreas Dilger]

Keith Owens writes:
> Andi Kleen <[e-mail]> wrote:
> >At one time someone had a script to grep objdump -S vmlinux for the
> >stack allocations generated by gcc and check them.
> 
> ftp://ftp.ocs.com.au/pub/kernel.stack.gz.  ix86 specific, probably gcc
> specific and it only picks up code that you compile.  The Stanford
> checker is much better.

I would probably agree.  Dawson said in a separate email that it would
be possible to enhance the checker to follow the call chains to measure
total stack usage.  Combining this with potential interrupt stack usage,
we may be able to eliminate some rare problems otherwise hard to find.

> >> On a side note, does anyone know if the kernel does checking if the
> >> stack overflowed at any time?
> >
> >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.
> 
> You cannot recover from a kernel stack overflow even with kdb.  The
> exception handler and kdb use the stack that just overflowed.

If it at least tells you that the stack has overflowed, and a backtrace
of the stack up to that point, that would at least be useful for fixing
the functions which caused the problem.

Also, allowing a config option to zero the stack at allocation would at
least allow the SysRQ-T code to tell you how much of the stack has
previously been in use so we can get an idea if we are close or not.

Given that the Stanford checker has discovered several individual 3kB+
stack allocations, it would surprise me if we didn't have stack overflows.
It may well be that people get mysterious hangs in these cases and have
no way to even diagnose the problem.  Maybe they are blaming the rare
hangs on hardware instead of software.

Cheers, Andreas
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert