lkml.org 
[lkml]   [1999]   [Mar]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: tracing a kernel stack corruption

On Tue, 23 Mar 1999, Fabien Klein wrote:

> Does anyone knows how to trace a kernel stack corruption error??

yes, you can use the IKD ('Integrated Kernel Debugging') patch, but maybe
the solution is simpler than that:

> I use a program wich performs ioctl to an experimental network driver of
> my own
> At the end of this process ( when the release() function is called ), it
> seems that the usual contents of the kernel_stack_page element
> (0xdeadbeef) from the task_struct strucure has been crushed somewhere (
> I don t know how it is possible 'cause I don t play with any
> task_struct...)

One important kernel programming rule, at most ~7K should be used as stack
variables. (~4k on 2.0, thus a good guideline is to never allocate more
than 3k). Most probably the problem is that you allocate some big
structure on the kernel stack:

myioctl ()
{
char buff [10000];

....
}

use kmalloc() instead.

if you cannot find it, then you can use IKD which has a small extension
called 'stack status monitor', which simply saves the function's address
that used the most stackspace. (/proc/stack_monitor, or something like
that). Then you can work down all those functions that use too much stack.

-- mingo


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:50    [W:0.030 / U:0.296 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site