On Fri, May 25, 2001 at 07:52:02AM -0400, Brian Gerst wrote:
> Actually, you will never get a stack fault exception, since with a flat
> stack segment you can never get a limit violation. All you will do is
> corrupt the data in task struct and cause an oops later on when the
> kernel tries to
On Fri, May 25, 2001 at 07:52:02AM -0400, Brian Gerst wrote:
Actually, you will never get a stack fault exception, since with a flat
stack segment you can never get a limit violation. All you will do is
corrupt the data in task struct and cause an oops later on when the
kernel tries to use
On Sat, 26 May 2001, Keith Owens wrote:
> On Fri, 25 May 2001 08:31:24 -0700 (PDT),
> dean gaudet <[EMAIL PROTECTED]> wrote:
> >another possibility for a debugging mode for the kernel would be to hack
> >gcc to emit something like the following in the prologue of every function
> >(after the
On Fri, 25 May 2001, Jonathan Lundell wrote:
> At 8:45 AM -0700 2001-05-25, dean gaudet wrote:
> >i think it really depends on how you use current -- here's an alternative
> >usage which can fold the extra addition into the structure offset
> >calculations, and moves the task struct to the top
At 8:45 AM -0700 2001-05-25, dean gaudet wrote:
>i think it really depends on how you use current -- here's an alternative
>usage which can fold the extra addition into the structure offset
>calculations, and moves the task struct to the top of the stack.
>
>not that this really solves anything,
On Fri, 25 May 2001 08:31:24 -0700 (PDT),
dean gaudet <[EMAIL PROTECTED]> wrote:
>another possibility for a debugging mode for the kernel would be to hack
>gcc to emit something like the following in the prologue of every function
>(after the frame is allocated):
IKD already does that, via the
On Fri, 25 May 2001, Andi Kleen wrote:
> On Fri, May 25, 2001 at 04:03:57PM +0200, Oliver Neukum wrote:
> > Is there a reason for the task structure to be at the bottom rather than the
> > top of these two pages ?
>
> This way you save one addition for every current access; which adds to
> quite
another possibility for a debugging mode for the kernel would be to hack
gcc to emit something like the following in the prologue of every function
(after the frame is allocated):
movl %esp,%edx
andl %edx,0x1fff
cmpl %edx,sizeof(struct task)+512
jbe stack_overflow
> A small overflow of the kernel stack overwrites the struct task at the
> bottom of the stack, recovery is dubious at best because we rely on
> data in struct task. A large overflow of the kernel stack either
> corrupts the storage below this task's stack, which could hit anything,
> or it gets
Andi Kleen wrote:
>
> On Fri, May 25, 2001 at 07:52:02AM -0400, Brian Gerst wrote:
> > Actually, you will never get a stack fault exception, since with a flat
> > stack segment you can never get a limit violation. All you will do is
> > corrupt the data in task struct and cause an oops later on
On Fri, May 25, 2001 at 07:52:02AM -0400, Brian Gerst wrote:
> Actually, you will never get a stack fault exception, since with a flat
> stack segment you can never get a limit violation. All you will do is
> corrupt the data in task struct and cause an oops later on when the
> kernel tries to
Andi Kleen wrote:
>
> On Thu, May 24, 2001 at 05:08:40PM -0600, Andreas Dilger wrote:
> > I'm curious about this stack checker. Does it check for a single
> > stack allocation >= 1024 bytes, or does it also check for several
> > individual, smaller allocations which total >= 1024 bytes inside
>
On Fri, 25 May 2001 10:27:53 +0200,
Andi Kleen <[EMAIL PROTECTED]> wrote:
>On Fri, May 25, 2001 at 06:25:57PM +1000, Keith Owens wrote:
>> Nothing in arch/i386/kernel/traps.c uses a task gate, they are all
>> interrupt, trap, system or call gates. I guarantee that kdb on ix86
>> and ia64 uses
On Fri, May 25, 2001 at 06:25:57PM +1000, Keith Owens wrote:
> Nothing in arch/i386/kernel/traps.c uses a task gate, they are all
> interrupt, trap, system or call gates. I guarantee that kdb on ix86
> and ia64 uses the same kernel stack as the failing task, the starting
> point for the kdb
On Fri, 25 May 2001 10:20:15 +0200,
Andi Kleen <[EMAIL PROTECTED]> wrote:
>On Fri, May 25, 2001 at 04:53:47PM +1000, Keith Owens wrote:
>> The only way to avoid those problems is to move struct task out of the
>> kernel stack pages and to use a task gate for the stack fault and
>> double fault
On Fri, May 25, 2001 at 04:53:47PM +1000, Keith Owens wrote:
> The only way to avoid those problems is to move struct task out of the
> kernel stack pages and to use a task gate for the stack fault and
> double fault handlers, instead of a trap gate (all ix86 specific).
> Those methods are
On Fri, May 25, 2001 at 03:20:20PM +1000, Keith Owens wrote:
> ftp://ftp.ocs.com.au/pub/kernel.stack.gz. ix86 specific, probably gcc
> specific and it only picks up code that you compile. The Stanford
> checker is much better.
I have no complete understanding of the stanford checker, but I was
On Fri, 25 May 2001 08:11:07 +0100,
David Welch <[EMAIL PROTECTED]> wrote:
>Why not use a task gate for the double fault handler points to a
>per-processor TSS with a seperate stack. This would allow limited recovery
>from a kernel stack overlay.
It is far too late by then. struct task is at
On Fri, May 25, 2001 at 03:20:20PM +1000, Keith Owens wrote:
>
> >> On a side note, does anyone know if the kernel does checking if the
> >> stack overflowed at any time?
> >
> >You normally get a silent hang or worse a stack fault exception
> >(which linux/x86 without kdb cannot recover from)
Keith Owens writes:
> Andi Kleen <[EMAIL PROTECTED]> wrote:
> >At one time someone had a script to grep objdump -S vmlinux for the
> >stack allocations generated by gcc and check them.
>
> ftp://ftp.ocs.com.au/pub/kernel.stack.gz. ix86 specific, probably gcc
> specific and it only picks up code
Andi Kleen wrote:
On Thu, May 24, 2001 at 05:08:40PM -0600, Andreas Dilger wrote:
I'm curious about this stack checker. Does it check for a single
stack allocation = 1024 bytes, or does it also check for several
individual, smaller allocations which total = 1024 bytes inside
a single
On Fri, May 25, 2001 at 07:52:02AM -0400, Brian Gerst wrote:
Actually, you will never get a stack fault exception, since with a flat
stack segment you can never get a limit violation. All you will do is
corrupt the data in task struct and cause an oops later on when the
kernel tries to use
Andi Kleen wrote:
On Fri, May 25, 2001 at 07:52:02AM -0400, Brian Gerst wrote:
Actually, you will never get a stack fault exception, since with a flat
stack segment you can never get a limit violation. All you will do is
corrupt the data in task struct and cause an oops later on when
On Fri, 25 May 2001 08:31:24 -0700 (PDT),
dean gaudet [EMAIL PROTECTED] wrote:
another possibility for a debugging mode for the kernel would be to hack
gcc to emit something like the following in the prologue of every function
(after the frame is allocated):
IKD already does that, via the
On Fri, 25 May 2001, Andi Kleen wrote:
On Fri, May 25, 2001 at 04:03:57PM +0200, Oliver Neukum wrote:
Is there a reason for the task structure to be at the bottom rather than the
top of these two pages ?
This way you save one addition for every current access; which adds to
quite a few
On Sat, 26 May 2001, Keith Owens wrote:
On Fri, 25 May 2001 08:31:24 -0700 (PDT),
dean gaudet [EMAIL PROTECTED] wrote:
another possibility for a debugging mode for the kernel would be to hack
gcc to emit something like the following in the prologue of every function
(after the frame is
On Fri, May 25, 2001 at 03:20:20PM +1000, Keith Owens wrote:
On a side note, does anyone know if the kernel does checking if the
stack overflowed at any time?
You normally get a silent hang or worse a stack fault exception
(which linux/x86 without kdb cannot recover from) which gives
On Fri, 25 May 2001, Jonathan Lundell wrote:
At 8:45 AM -0700 2001-05-25, dean gaudet wrote:
i think it really depends on how you use current -- here's an alternative
usage which can fold the extra addition into the structure offset
calculations, and moves the task struct to the top of the
On Fri, May 25, 2001 at 06:25:57PM +1000, Keith Owens wrote:
Nothing in arch/i386/kernel/traps.c uses a task gate, they are all
interrupt, trap, system or call gates. I guarantee that kdb on ix86
and ia64 uses the same kernel stack as the failing task, the starting
point for the kdb
A small overflow of the kernel stack overwrites the struct task at the
bottom of the stack, recovery is dubious at best because we rely on
data in struct task. A large overflow of the kernel stack either
corrupts the storage below this task's stack, which could hit anything,
or it gets a
On Fri, 25 May 2001 10:27:53 +0200,
Andi Kleen [EMAIL PROTECTED] wrote:
On Fri, May 25, 2001 at 06:25:57PM +1000, Keith Owens wrote:
Nothing in arch/i386/kernel/traps.c uses a task gate, they are all
interrupt, trap, system or call gates. I guarantee that kdb on ix86
and ia64 uses the same
On Fri, 25 May 2001 08:11:07 +0100,
David Welch [EMAIL PROTECTED] wrote:
Why not use a task gate for the double fault handler points to a
per-processor TSS with a seperate stack. This would allow limited recovery
from a kernel stack overlay.
It is far too late by then. struct task is at the
At 8:45 AM -0700 2001-05-25, dean gaudet wrote:
i think it really depends on how you use current -- here's an alternative
usage which can fold the extra addition into the structure offset
calculations, and moves the task struct to the top of the stack.
not that this really solves anything,
On Fri, May 25, 2001 at 04:53:47PM +1000, Keith Owens wrote:
The only way to avoid those problems is to move struct task out of the
kernel stack pages and to use a task gate for the stack fault and
double fault handlers, instead of a trap gate (all ix86 specific).
Those methods are expensive,
On Fri, 25 May 2001 10:20:15 +0200,
Andi Kleen [EMAIL PROTECTED] wrote:
On Fri, May 25, 2001 at 04:53:47PM +1000, Keith Owens wrote:
The only way to avoid those problems is to move struct task out of the
kernel stack pages and to use a task gate for the stack fault and
double fault handlers,
Keith Owens writes:
Andi Kleen [EMAIL PROTECTED] wrote:
At one time someone had a script to grep objdump -S vmlinux for the
stack allocations generated by gcc and check them.
ftp://ftp.ocs.com.au/pub/kernel.stack.gz. ix86 specific, probably gcc
specific and it only picks up code that you
On Fri, May 25, 2001 at 03:20:20PM +1000, Keith Owens wrote:
ftp://ftp.ocs.com.au/pub/kernel.stack.gz. ix86 specific, probably gcc
specific and it only picks up code that you compile. The Stanford
checker is much better.
I have no complete understanding of the stanford checker, but I was
> From: Andrew Morton [mailto:[EMAIL PROTECTED]]
>
> Andreas Dilger wrote:
> >
> > On a side note, does anyone know if the kernel does checking if the
> > stack overflowed at any time?
>
> There's a little bit of code in show_task() which calculates
> how close this task ever got to
Andreas Dilger wrote:
>
> Dawson Engler writes:
> > Here are 37 errors where variables >= 1024 bytes are allocated on a
> > function's stack.
>
> First of all, thanks very much for the work you are doing. It really
> is useful, and a good way to catch those very rare error cases that
> would
> > Ah, nice --- I keep meaning to tell the checker to demote its warning
> > about NULL bugs or large stack vars in __init routines and/or routines
> > that have the substring "init" in them ;-)
>
> Please, don't. These functions are often used from/as init_module(),
> so they must handle the
On Thu, 24 May 2001, Dawson Engler wrote:
> > check_nmi_watchdog() is __init and we know exactly when it's called.
> > The interesting cases (SMP kernel, since for UP NR_CPUS==1) are:
>
> Ah, nice --- I keep meaning to tell the checker to demote its warning
> about NULL bugs or large stack
> check_nmi_watchdog() is __init and we know exactly when it's called.
> The interesting cases (SMP kernel, since for UP NR_CPUS==1) are:
Ah, nice --- I keep meaning to tell the checker to demote its warning
about NULL bugs or large stack vars in __init routines and/or routines
that have the
On Thu, May 24, 2001 at 05:08:40PM -0600, Andreas Dilger wrote:
> I'm curious about this stack checker. Does it check for a single
> stack allocation >= 1024 bytes, or does it also check for several
> individual, smaller allocations which total >= 1024 bytes inside
> a single function? That
Dawson Engler writes:
> Here are 37 errors where variables >= 1024 bytes are allocated on a
> function's stack.
First of all, thanks very much for the work you are doing. It really
is useful, and a good way to catch those very rare error cases that
would not otherwise be fixed.
I'm curious
At 22:10 24/05/2001, Dawson Engler wrote:
[snip]
>-
>[BUG]
>/u2/engler/mc/oses/linux/2.4.4-ac8/fs/ntfs/super.c:352:ntfs_get_free_cluster_count:
>ERROR:VAR:352:352: suspicious var 'bits' = 2048 bytes:352 [nbytes=2048]
>
>static int
Hi All,
Here are 37 errors where variables >= 1024 bytes are allocated on a function's
stack.
Summary for
2.4.4ac8-specific errors = 9
2.4.4-specific errors = 0
Common errors = 28
Hi All,
Here are 37 errors where variables = 1024 bytes are allocated on a function's
stack.
Summary for
2.4.4ac8-specific errors = 9
2.4.4-specific errors = 0
Common errors = 28
At 22:10 24/05/2001, Dawson Engler wrote:
[snip]
-
[BUG]
/u2/engler/mc/oses/linux/2.4.4-ac8/fs/ntfs/super.c:352:ntfs_get_free_cluster_count:
ERROR:VAR:352:352: suspicious var 'bits' = 2048 bytes:352 [nbytes=2048]
static int
Dawson Engler writes:
Here are 37 errors where variables = 1024 bytes are allocated on a
function's stack.
First of all, thanks very much for the work you are doing. It really
is useful, and a good way to catch those very rare error cases that
would not otherwise be fixed.
I'm curious about
On Thu, May 24, 2001 at 05:08:40PM -0600, Andreas Dilger wrote:
I'm curious about this stack checker. Does it check for a single
stack allocation = 1024 bytes, or does it also check for several
individual, smaller allocations which total = 1024 bytes inside
a single function? That would be
check_nmi_watchdog() is __init and we know exactly when it's called.
The interesting cases (SMP kernel, since for UP NR_CPUS==1) are:
Ah, nice --- I keep meaning to tell the checker to demote its warning
about NULL bugs or large stack vars in __init routines and/or routines
that have the
On Thu, 24 May 2001, Dawson Engler wrote:
check_nmi_watchdog() is __init and we know exactly when it's called.
The interesting cases (SMP kernel, since for UP NR_CPUS==1) are:
Ah, nice --- I keep meaning to tell the checker to demote its warning
about NULL bugs or large stack vars in
Ah, nice --- I keep meaning to tell the checker to demote its warning
about NULL bugs or large stack vars in __init routines and/or routines
that have the substring init in them ;-)
Please, don't. These functions are often used from/as init_module(),
so they must handle the case when
Andreas Dilger wrote:
Dawson Engler writes:
Here are 37 errors where variables = 1024 bytes are allocated on a
function's stack.
First of all, thanks very much for the work you are doing. It really
is useful, and a good way to catch those very rare error cases that
would not
From: Andrew Morton [mailto:[EMAIL PROTECTED]]
Andreas Dilger wrote:
On a side note, does anyone know if the kernel does checking if the
stack overflowed at any time?
There's a little bit of code in show_task() which calculates
how close this task ever got to overrunning its kernel
55 matches
Mail list logo
