How to find out kernel stack over flow?

How to find out kernel stack over flow?

[nazim khan]

Hi,

I suspect that one of my module that I am inserting in
the kernel may be causing the stack overflow which is
leading to kernel crash (may because it is corrupting
some one lese memory).

How can I find this out?

Thanks in advance.
Nazim

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: How to find out kernel stack over flow?

[Michal Schmidt]

nazim khan wrote:
> I suspect that one of my module that I am inserting in
> the kernel may be causing the stack overflow which is
> leading to kernel crash (may because it is corrupting
> some one lese memory).
> 
> How can I find this out?

You could enable CONFIG_DEBUG_STACKOVERFLOW.
If you showed us your module's source code, someone might see the bug.

Michal

Re: How to find out kernel stack over flow?

[Neil Horman]

On Wed, Sep 07, 2005 at 10:18:13AM +0200, Michal Schmidt wrote:
> nazim khan wrote:
> >I suspect that one of my module that I am inserting in
> >the kernel may be causing the stack overflow which is
> >leading to kernel crash (may because it is corrupting
> >some one lese memory).
> >
> >How can I find this out?
> 
> You could enable CONFIG_DEBUG_STACKOVERFLOW.
> If you showed us your module's source code, someone might see the bug.
> 
> Michal
> -
> 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/

Additionally, if you have netconsole/netdump set up, you can examine the
resultant core file with the crash utility to find telltale signs of an
overflow.  Nominally a stack overflow results in the corruption of data at the
end of a neighboring task_struct.

Regards
Neil

-- 
/***************************************************
 *Neil Horman
 *Software Engineer
 *gpg keyid: 1024D / 0x92A74FA1 - http://pgp.mit.edu
 ***************************************************/

Re: How to find out kernel stack over flow?

[nazim khan]

Thanks Michal for your response,

I forgot to mention that I am using linux 2.4.26,
and STACKOVERFLOW option is not available here.

regards,
Nazim

--- Michal Schmidt <xschmi00@stud.feec.vutbr.cz>
wrote:

> nazim khan wrote:
> > I suspect that one of my module that I am
> inserting in
> > the kernel may be causing the stack overflow which
> is
> > leading to kernel crash (may because it is
> corrupting
> > some one lese memory).
> > 
> > How can I find this out?
> 
> You could enable CONFIG_DEBUG_STACKOVERFLOW.
> If you showed us your module's source code, someone
> might see the bug.
> 
> Michal
> 



	
		
______________________________________________________
Click here to donate to the Hurricane Katrina relief effort.
http://store.yahoo.com/redcross-donate3/

Re: How to find out kernel stack over flow?

[Neil Horman]

On Wed, Sep 07, 2005 at 10:17:16PM -0700, nazim khan wrote:
> Thanks Michal for your response,
> 
> I forgot to mention that I am using linux 2.4.26,
> and STACKOVERFLOW option is not available here.
> 
> regards,
> Nazim
> 
It shouldn't be a difficult thing to hand-edit in (or at least an approximation
thereof).  Its really just a comparison of the current stack pointer in relation
to the current task_struct preformed in the do_IRQ function (so that it check
stack depth on interrupts).

Alternative to this method, or the netdump method I mentioned earlier.  If you
have some idea of which function(s) you are likely to be executing when the
stack overflows, you can also use -finstrument-functions as a finer grained
approach to detecting the problem.

Regards
Neil

> --- Michal Schmidt <xschmi00@stud.feec.vutbr.cz>
> wrote:
> 
> > nazim khan wrote:
> > > I suspect that one of my module that I am
> > inserting in
> > > the kernel may be causing the stack overflow which
> > is
> > > leading to kernel crash (may because it is
> > corrupting
> > > some one lese memory).
> > > 
> > > How can I find this out?
> > 
> > You could enable CONFIG_DEBUG_STACKOVERFLOW.
> > If you showed us your module's source code, someone
> > might see the bug.
> > 
> > Michal
> > 
> 
> 
> 
> 	
> 		
> ______________________________________________________
> Click here to donate to the Hurricane Katrina relief effort.
> http://store.yahoo.com/redcross-donate3/
> -
> 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/

-- 
/***************************************************
 *Neil Horman
 *Software Engineer
 *gpg keyid: 1024D / 0x92A74FA1 - http://pgp.mit.edu
 ***************************************************/