[Top] [All Lists]

Re: How to detect STACKOVEFLOW on mips

To: Phil Staub <>
Subject: Re: How to detect STACKOVEFLOW on mips
From: Ralf Baechle <>
Date: Wed, 30 Jun 2010 15:57:25 +0100
Cc: Adam Jiang <>,
In-reply-to: <>
References: <> <>
User-agent: Mutt/1.5.20 (2009-08-17)
On Wed, Jun 30, 2010 at 07:27:10AM -0700, Phil Staub wrote:

> >I'm having a problem with kernel mode stack on my box. It seems that
> >STACKOVERFLOW happened to Linux kernel. However, I can't prove it
> >because the lack of any detection in __do_IRQ() function just like on
> >the other architectures. If you know something about, please help me
> >on following two questions.
> >- Is there any possible to do this on MIPS?
> The mechanisms I know about for detecting stack overflow include:
> 1. Use of the MMU - stack ends at a page boundary, adjacent page is
> either unmapped or mapped read-only and causes an exception if violated.

Won't easily work on MIPS as the stack is allocated in KSEG0 / XKPHYS
which are unmapped segments.  It would be necessary to relocate the stack
into a mapped space.

Ultra-ancient Linux/MIPS kernels actually used to do that but that code
may well even predate everything that still exists on

> 2. Hooks inserted into toolchain to cause any stack decrement to be
> first tested against a limit.
> 3. Fill entire stack with a recognizable pattern before first
> use. After suspected stack overflow, check to see if the pattern has
> been disturbed in the area of the stack limit.

This was afaik never ported to MIPS though that'd be easy.

> (Disclaimer: I've used all of these in some form on other OSes, but
> not on Linux. Someone else may have a more directly relevant answer.)
> >- or, more simple question, how could I get the address $sp pointed by
> >asm() notation in C?
> How about something like:
> {
>       long x;
>       ...
>       asm("move %0,$29":"=g"(x));
>       ...
> }

That will do.  Or even something portable like:

        unsigned long foo;

        return &foo;

which used to work (GNU alloca and others were using this) but I'm sure
GCC has learned how to optimize this to shreds.


<Prev in Thread] Current Thread [Next in Thread>