linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Stack overflow
@ 2003-01-24  7:08 Madhavi
  2003-01-24  7:53 ` Linux Geek
  0 siblings, 1 reply; 13+ messages in thread
From: Madhavi @ 2003-01-24  7:08 UTC (permalink / raw)
  To: linux-kernel


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.


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Stack overflow
  2003-01-24  7:08 Stack overflow Madhavi
@ 2003-01-24  7:53 ` Linux Geek
  2003-01-24 15:32   ` GrandMasterLee
  0 siblings, 1 reply; 13+ messages in thread
From: Linux Geek @ 2003-01-24  7:53 UTC (permalink / raw)
  To: Madhavi; +Cc: linux-kernel

>
>
>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.


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Stack overflow
  2003-01-24  7:53 ` Linux Geek
@ 2003-01-24 15:32   ` GrandMasterLee
  2003-01-24 15:41     ` Madhavi
  0 siblings, 1 reply; 13+ messages in thread
From: GrandMasterLee @ 2003-01-24 15:32 UTC (permalink / raw)
  To: Linux Geek; +Cc: Madhavi, linux-kernel

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.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Stack overflow
  2003-01-24 15:32   ` GrandMasterLee
@ 2003-01-24 15:41     ` Madhavi
  2003-01-24 16:42       ` Richard B. Johnson
  2003-01-24 16:52       ` Gianni Tedesco
  0 siblings, 2 replies; 13+ messages in thread
From: Madhavi @ 2003-01-24 15:41 UTC (permalink / raw)
  To: GrandMasterLee; +Cc: Linux Geek, linux-kernel


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.


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Stack overflow
  2003-01-24 15:41     ` Madhavi
@ 2003-01-24 16:42       ` Richard B. Johnson
  2003-01-24 16:52       ` Gianni Tedesco
  1 sibling, 0 replies; 13+ messages in thread
From: Richard B. Johnson @ 2003-01-24 16:42 UTC (permalink / raw)
  To: Madhavi; +Cc: GrandMasterLee, Linux Geek, linux-kernel

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.



^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Stack overflow
  2003-01-24 15:41     ` Madhavi
  2003-01-24 16:42       ` Richard B. Johnson
@ 2003-01-24 16:52       ` Gianni Tedesco
  1 sibling, 0 replies; 13+ messages in thread
From: Gianni Tedesco @ 2003-01-24 16:52 UTC (permalink / raw)
  To: Madhavi; +Cc: GrandMasterLee, Linux Geek, linux-kernel

[-- 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 --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: stack overflow
  2003-09-12 23:18     ` Alan Cox
@ 2003-09-12 23:25       ` William Lee Irwin III
  0 siblings, 0 replies; 13+ messages in thread
From: William Lee Irwin III @ 2003-09-12 23:25 UTC (permalink / raw)
  To: Alan Cox; +Cc: Breno, Linux Kernel Mailing List

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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: stack overflow
  2003-09-12 23:06   ` William Lee Irwin III
  2003-09-12 19:23     ` Breno
@ 2003-09-12 23:18     ` Alan Cox
  2003-09-12 23:25       ` William Lee Irwin III
  1 sibling, 1 reply; 13+ messages in thread
From: Alan Cox @ 2003-09-12 23:18 UTC (permalink / raw)
  To: William Lee Irwin III; +Cc: Breno, Linux Kernel Mailing List

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


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: stack overflow
  2003-09-12 22:50 ` Andreas Dilger
  2003-09-12 19:14   ` Breno
@ 2003-09-12 23:06   ` William Lee Irwin III
  2003-09-12 19:23     ` Breno
  2003-09-12 23:18     ` Alan Cox
  1 sibling, 2 replies; 13+ messages in thread
From: William Lee Irwin III @ 2003-09-12 23:06 UTC (permalink / raw)
  To: Breno, Kernel List

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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: stack overflow
  2003-09-12 17:53 stack overflow Breno
@ 2003-09-12 22:50 ` Andreas Dilger
  2003-09-12 19:14   ` Breno
  2003-09-12 23:06   ` William Lee Irwin III
  0 siblings, 2 replies; 13+ messages in thread
From: Andreas Dilger @ 2003-09-12 22:50 UTC (permalink / raw)
  To: Breno; +Cc: Kernel List

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/


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: stack overflow
  2003-09-12 23:06   ` William Lee Irwin III
@ 2003-09-12 19:23     ` Breno
  2003-09-12 23:18     ` Alan Cox
  1 sibling, 0 replies; 13+ messages in thread
From: Breno @ 2003-09-12 19:23 UTC (permalink / raw)
  To: William Lee Irwin III, Kernel List

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/


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: stack overflow
  2003-09-12 22:50 ` Andreas Dilger
@ 2003-09-12 19:14   ` Breno
  2003-09-12 23:06   ` William Lee Irwin III
  1 sibling, 0 replies; 13+ messages in thread
From: Breno @ 2003-09-12 19:14 UTC (permalink / raw)
  To: Andreas Dilger; +Cc: Kernel List

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/


^ permalink raw reply	[flat|nested] 13+ messages in thread

* stack overflow
@ 2003-09-12 17:53 Breno
  2003-09-12 22:50 ` Andreas Dilger
  0 siblings, 1 reply; 13+ messages in thread
From: Breno @ 2003-09-12 17:53 UTC (permalink / raw)
  To: Kernel List

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



^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2003-09-12 23:26 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-01-24  7:08 Stack overflow Madhavi
2003-01-24  7:53 ` Linux Geek
2003-01-24 15:32   ` GrandMasterLee
2003-01-24 15:41     ` Madhavi
2003-01-24 16:42       ` Richard B. Johnson
2003-01-24 16:52       ` Gianni Tedesco
2003-09-12 17:53 stack overflow Breno
2003-09-12 22:50 ` Andreas Dilger
2003-09-12 19:14   ` Breno
2003-09-12 23:06   ` William Lee Irwin III
2003-09-12 19:23     ` Breno
2003-09-12 23:18     ` Alan Cox
2003-09-12 23:25       ` William Lee Irwin III

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).