Re: top stack (l)users for 2.5.69

["Jörn Engel" <joern@wohnheim.fh-wedel.de>]

On Wed, 7 May 2003 10:13:55 -0700, Jonathan Lundell wrote:
> At 10:16am -0400 5/7/03, Richard B. Johnson wrote:
> >Nope. Just don't steal thousands of CPU cycles to make something
> >"pretty". Obviously something called recursively with a 2k buffer
> >on the stack is going to break. However one has to actually
> >look at the code and determine the best (if any) way to reduce
> >stack usage. For instance, some persons may just "like" 0x400 for
> >the size of a temporary buffer when, in fact, 29 bytes are actually
> >used.
> >
> >FYI, one can make a module that will show the maximum amount
> >of stack ever used IFF the stack gets zeroed before use upon
> >kernel startup. Would this be useful or has it already been
> >done?
> 
> There's at least one patch floating around to do that; we've used it 
> to help track down some stack overflow problems.

Do you have a URL or can you post that patch? Sounds very useful for
information gathering.

> Does 2.5 use a separate interrupt stack? (Excuse my ignorance; I 
> haven't been paying attention.) Total stack-page usage in the 2.4 
> model, at any rate, is the sum of the task struct, the usage of any 
> task-level thread (system calls, pretty much), any softirq (including 
> the network protocol & routing handlers, and any netfilter modules), 
> and some number of possibly-nested hard interrupts.

Depends on the architecture. s390 does, ppc didn't as of 2.4.2, the
rest I'm not sure about. But this is another requirement for stack
reduction to 4k for most platforms, if not all.

> One thing that would help (aside from separate interrupt stacks) 
> would be a guard page below the stack. That wouldn't require any 
> physical memory to be reserved, and would provide positive indication 
> of stack overflow without significant runtime overhead.

Yes, that should work. It needs some additional code in the page fault
handler to detect this case, but that shouldn't slow the system down
too much.

Jörn

-- 
And spam is a useful source of entropy for /dev/random too!
-- Jasmine Strong