Stack overflow

Stack overflow

[Madhavi]

Hi

I am testing a PCI network device driver on linux-2.4.19.

I have observed a peculiar problem during testing.

I have a functionality which works well if the code whcih performs this
function is embedded in the required function. If this functionality is
implemented as a separate function, and this function is called at the
required place, the system crashes. I have used KDB for debugging. But,
KDB also fails when this system crash occurs.

Could this be because of any function stack overflow? I am new to this
field. Could someone through some light on this.

Thanks in advacne.

regards
Madhavi.

Re: Stack overflow

[Linux Geek]

>
>
>I have a functionality which works well if the code whcih performs this
>function is embedded in the required function. If this functionality is
>implemented as a separate function, and this function is called at the
>required place, the system crashes. I have used KDB for debugging. But,
>  
>
    I'd suggest check the args passed to the function and the sizes they 
would consume when they are passed as 'call by value'.
Try to pass them as pointers maybe.

Yes, i think there is a limit on kernel stack but not i'm not too sure 
about the number.

Re: Stack overflow

[GrandMasterLee]

On Fri, 2003-01-24 at 01:53, Linux Geek wrote:
> >
> >
> >I have a functionality which works well if the code whcih performs this
> >function is embedded in the required function. If this functionality is
> >implemented as a separate function, and this function is called at the
> >required place, the system crashes. I have used KDB for debugging. But,
> >  
> >
>     I'd suggest check the args passed to the function and the sizes they 
> would consume when they are passed as 'call by value'.
> Try to pass them as pointers maybe.
> 
> Yes, i think there is a limit on kernel stack but not i'm not too sure 
> about the number.

The kernel has an 8K stack max. That said, it *could* be your stack. Do
you get any panics or oops? If so, you *could* write them down :-D And
debug them later. If it appears corrupted, then it's probably stack.

Re: Stack overflow

[Madhavi]

On 24 Jan 2003, GrandMasterLee wrote:

> On Fri, 2003-01-24 at 01:53, Linux Geek wrote:
> > >
> > >
> > >I have a functionality which works well if the code whcih performs this
> > >function is embedded in the required function. If this functionality is
> > >implemented as a separate function, and this function is called at the
> > >required place, the system crashes. I have used KDB for debugging. But,
> > >
> > >
> >     I'd suggest check the args passed to the function and the sizes they
> > would consume when they are passed as 'call by value'.
> > Try to pass them as pointers maybe.
> >
> > Yes, i think there is a limit on kernel stack but not i'm not too sure
> > about the number.
>
> The kernel has an 8K stack max. That said, it *could* be your stack. Do
> you get any panics or oops? If so, you *could* write them down :-D And
> debug them later. If it appears corrupted, then it's probably stack.
>

I am getting a panic saying "attempted to kill idle task". The call trace
scrolls through for 4-5 pages. I have also observed complete system hang a
few times.

How can I solve this problem, supposing I can't avoid that function call?
Any pointers regarding this would be of great help for me.

thanks & regards
Madhavi.

Re: Stack overflow

[Richard B. Johnson]

On Fri, 24 Jan 2003, Madhavi wrote:

> 
> On 24 Jan 2003, GrandMasterLee wrote:
> 
> > On Fri, 2003-01-24 at 01:53, Linux Geek wrote:
> > > >
> > > >
> > > >I have a functionality which works well if the code whcih performs this
> > > >function is embedded in the required function. If this functionality is
> > > >implemented as a separate function, and this function is called at the
> > > >required place, the system crashes. I have used KDB for debugging. But,
> > > >
> > > >
> > >     I'd suggest check the args passed to the function and the sizes they
> > > would consume when they are passed as 'call by value'.
> > > Try to pass them as pointers maybe.
> > >
> > > Yes, i think there is a limit on kernel stack but not i'm not too sure
> > > about the number.
> >
> > The kernel has an 8K stack max. That said, it *could* be your stack. Do
> > you get any panics or oops? If so, you *could* write them down :-D And
> > debug them later. If it appears corrupted, then it's probably stack.
> >
> 
> I am getting a panic saying "attempted to kill idle task". The call trace
> scrolls through for 4-5 pages. I have also observed complete system hang a
> few times.
> 
> How can I solve this problem, supposing I can't avoid that function call?
> Any pointers regarding this would be of great help for me.
> 
> thanks & regards
> Madhavi.
> 

Make a user-mode 'main()' test program that calls your function with
the required parameters. Link it with your function and run it either
with gdb or with lots of ordinary printf statements.

You can resolve all missing globals, including functions, with
simple 'ints' as long as they are not accessed in your code. This
lets you test practically anything in user-mode when, if you
screw up, you just have a core file and don't have to re-boot.

Most all of the modules that I write for embedded systems are
initially tested this way. That lets me get linked-lists and
other easy-to-muck-up things working correctly before I throw
it off the cliff, hoping it will fly. My user-mode code calls
ISRs, actually accessing hardware in most cases (iopl(3) allows
this).

Also, PCI interrupts are level interrupts. Do not enable interrupts
in your ISR until you have serviced the reason why you got the
interrupt in the first place, otherwise the ISR will be interrupted
by the same interrupt...,
 by the same interrupt...,
  by the same interrupt...,
   until you crash.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.

Re: Stack overflow

[Gianni Tedesco]

[-- Attachment #1: Type: text/plain, Size: 399 bytes --]

On Fri, 2003-01-24 at 15:41, Madhavi wrote:
> How can I solve this problem, supposing I can't avoid that function call?
> Any pointers regarding this would be of great help for me.

post source code.

-- 
// Gianni Tedesco (gianni at scaramanga dot co dot uk)
lynx --source www.scaramanga.co.uk/gianni-at-ecsc.asc | gpg --import
8646BE7D: 6D9F 2287 870E A2C9 8F60 3A3C 91B5 7669 8646 BE7D

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

stack overflow

[Breno]

Hi ... this is my idea to check a stack overflow. What do you think ?


#define STACK_LIMIT (1024*8192)/PAGE_SIZE

int check_stack_overflow(struct task_struct *tsk)
{

    unsigned long stack_size,stack_addr,stack_ptr;
    int i;

         if(tsk->mm != NULL)
         {
                  stack_addr = tsk->mm->start_stack;

                  stack_ptr = tsk->thread.esp;

                  for(i=0; i < stack_ptr; i++)
                  stack_addr++;

                  stack_size = (stack_addr - stack_ptr)/PAGE_SIZE;

                  if(stack_size > ( STACK_LIMIT - 1))
                  {
                               printk(KERN_CRIT"Process %s : pid %d -
                                Can cause stack
overflow\n",tsk->comm,tsk->pid);
                               return 0;
                  }
         }
return 0;
}

att,
Breno

Re: stack overflow

[Andreas Dilger]

On Sep 12, 2003  18:53 +0100, Breno wrote:
> Hi ... this is my idea to check a stack overflow. What do you think ?
> 
> #define STACK_LIMIT (1024*8192)/PAGE_SIZE
> 
> int check_stack_overflow(struct task_struct *tsk)
> {
> 
>     unsigned long stack_size,stack_addr,stack_ptr;
>     int i;
> 
>          if(tsk->mm != NULL)
>          {
>                   stack_addr = tsk->mm->start_stack;
> 
>                   stack_ptr = tsk->thread.esp;
> 
>                   for(i=0; i < stack_ptr; i++)
>                   stack_addr++;
> 
>                   stack_size = (stack_addr - stack_ptr)/PAGE_SIZE;
> 
>                   if(stack_size > ( STACK_LIMIT - 1))

Well, with the exception of the fact that STACK_LIMIT is 8MB, and kernel
stacks are only 8kB (on i386)...

Also, see "do_IRQ()" (i386) for CONFIG_DEBUG_STACKOVERFLOW to see this already.

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/

Re: stack overflow

[Breno]

I think that size limit of user stack is 8mb

Breno
----- Original Message -----
From: "Andreas Dilger" <adilger@clusterfs.com>
To: "Breno" <brenosp@brasilsec.com.br>
Cc: "Kernel List" <linux-kernel@vger.kernel.org>
Sent: Friday, September 12, 2003 11:50 PM
Subject: Re: stack overflow


> On Sep 12, 2003  18:53 +0100, Breno wrote:
> > Hi ... this is my idea to check a stack overflow. What do you think ?
> >
> > #define STACK_LIMIT (1024*8192)/PAGE_SIZE
> >
> > int check_stack_overflow(struct task_struct *tsk)
> > {
> >
> >     unsigned long stack_size,stack_addr,stack_ptr;
> >     int i;
> >
> >          if(tsk->mm != NULL)
> >          {
> >                   stack_addr = tsk->mm->start_stack;
> >
> >                   stack_ptr = tsk->thread.esp;
> >
> >                   for(i=0; i < stack_ptr; i++)
> >                   stack_addr++;
> >
> >                   stack_size = (stack_addr - stack_ptr)/PAGE_SIZE;
> >
> >                   if(stack_size > ( STACK_LIMIT - 1))
>
> Well, with the exception of the fact that STACK_LIMIT is 8MB, and kernel
> stacks are only 8kB (on i386)...
>
> Also, see "do_IRQ()" (i386) for CONFIG_DEBUG_STACKOVERFLOW to see this
already.
>
> Cheers, Andreas
> --
> Andreas Dilger
> http://sourceforge.net/projects/ext2resize/
> http://www-mddsp.enel.ucalgary.ca/People/adilger/
>
> -
> 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/

Re: stack overflow

[William Lee Irwin III]

On Fri, Sep 12, 2003 at 04:50:47PM -0600, Andreas Dilger wrote:
> Well, with the exception of the fact that STACK_LIMIT is 8MB, and kernel
> stacks are only 8kB (on i386)...
> Also, see "do_IRQ()" (i386) for CONFIG_DEBUG_STACKOVERFLOW to see this already.

What he actually wants is in-kernel user stack overflow checking, which
is basically impossible since user stacks are demand paged. He's been
told this before and failed to absorb it.

There have been attempts to use i386 segmentation for stack limit
checks written but they should probably not be confused with this.


-- wli

Re: stack overflow

[Breno]

Wli,

Exactly that stack users are demand paged , you can calculate the size of
stack. This is will impossible or more difficult to do if you have more that
one mm->start_stack  :)

att
Breno

----- Original Message -----
From: "William Lee Irwin III" <wli@holomorphy.com>
To: "Breno" <brenosp@brasilsec.com.br>; "Kernel List"
<linux-kernel@vger.kernel.org>
Sent: Saturday, September 13, 2003 12:06 AM
Subject: Re: stack overflow


> On Fri, Sep 12, 2003 at 04:50:47PM -0600, Andreas Dilger wrote:
> > Well, with the exception of the fact that STACK_LIMIT is 8MB, and kernel
> > stacks are only 8kB (on i386)...
> > Also, see "do_IRQ()" (i386) for CONFIG_DEBUG_STACKOVERFLOW to see this
already.
>
> What he actually wants is in-kernel user stack overflow checking, which
> is basically impossible since user stacks are demand paged. He's been
> told this before and failed to absorb it.
>
> There have been attempts to use i386 segmentation for stack limit
> checks written but they should probably not be confused with this.
>
>
> -- wli
> -
> 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/

Re: stack overflow

[Alan Cox]

On Sad, 2003-09-13 at 00:06, William Lee Irwin III wrote:
> What he actually wants is in-kernel user stack overflow checking, which
> is basically impossible since user stacks are demand paged. He's been
> told this before and failed to absorb it.

We will fault and error on a user stack exceed. You need to use
sigaltstack to catch it for obvious reasons. You can also use mmap and
drop in red zones on user space stacks

Re: stack overflow

[William Lee Irwin III]

On Sad, 2003-09-13 at 00:06, William Lee Irwin III wrote:
>> What he actually wants is in-kernel user stack overflow checking, which
>> is basically impossible since user stacks are demand paged. He's been
>> told this before and failed to absorb it.

On Sat, Sep 13, 2003 at 12:18:32AM +0100, Alan Cox wrote:
> We will fault and error on a user stack exceed. You need to use
> sigaltstack to catch it for obvious reasons. You can also use mmap and
> drop in red zones on user space stacks

Stack rlimits are fine and we already do those; the rest sounds like
something userspace has to do.


-- wli