stack overflow?

stack overflow?

[Christian Widmer]

hi

i saw very strange behaviour when debuging my modules and i start to think 
about stack overflow. i know that the kernel stack of eache process is some
what smaller than 8KB. but how big is the kernelstack during interrupt time
when executing tasklets?

thanks 
chris

Re: stack overflow?

[Brian Gerst]

Christian Widmer wrote:
> 
> hi
> 
> i saw very strange behaviour when debuging my modules and i start to think
> about stack overflow. i know that the kernel stack of eache process is some
> what smaller than 8KB. but how big is the kernelstack during interrupt time
> when executing tasklets?

Depends on the architecture, but on the x86 there is no stack switch
when you receive an interrupt in kernel mode.  Thus, if too many
interrupts occur you could potentially overflow the stack.  If
interrupted from user mode the stack switches to the top of the kernel
stack.

--

				Brian Gerst

Re: stack overflow?

[Christian Widmer]

On Wednesday 26 September 2001 15:29, you wrote:
> Christian Widmer wrote:
> > hi
> >
> > i saw very strange behaviour when debuging my modules and i start to
> > think about stack overflow. i know that the kernel stack of eache process
> > is some what smaller than 8KB. but how big is the kernelstack during
> > interrupt time when executing tasklets?
>
> Depends on the architecture, but on the x86 there is no stack switch
> when you receive an interrupt in kernel mode.  Thus, if too many
> interrupts occur you could potentially overflow the stack.  If
> interrupted from user mode the stack switches to the top of the kernel
> stack.

thanks
i could verify that it was a stackoverflow. but this was due to an 
unexpected behaviour of gcc not because of too may interrupts :) 
i realiesd that when i had a look at the assemby output of my code. 
i had a macro that defined its local variables (256 byte). this macro 
was used n times and gcc allocates n * 256 bytes at the function entry 
point also it actualy only needs 256 byte. is his allocation strategy 
not silly?

chris
	

Stack overflow ?

[Ravi Wijayaratne]

Hi All,

I applied Tigran's 8k->16k large stack patch to
2.4.18. When I look at /proc/stack I see that a
process insmod is using 0x2000=8k stack. My
undertstanding is that the stack size increase should
not have affected the amount of stack used by any
process. 

If that is the case how did my system survive without
the patch when the whole task_struct is wiped out by a
process using a stack size of 8k. I have been running
heavy I/O on this system (A file server) for a couple
of days without the patch. Nothing adverese happened.

Can this happen or are the contents put to /proc/stack
in the patch is wrong. I looked at the patch carefully
and all seems to be ok to me. Has any one had a
similar experience before ?

To further analyze the problem I called BUG() when the
stack size ever increased more than 8k in schedule()
After running ksymoops I see that this is happening
when I try to access routines in i2c.o which seem to
have a deep call stack.

Thank you
Ravi

=====
------------------------------
Ravi Wijayaratne

__________________________________________________
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com