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 fram
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
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 C
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 us
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, May 25, 2001 at 06:31:20PM +1000, Keith Owens wrote:
> That is exactly what I said above, a separate fault task with its own
> stack for every cpu. But there is no point in doing this to detect a
> hardware stack overflow when the overflow has already corrupted the
> struct task which is
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 th
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 backt
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 ha
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 expensi
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 t
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) w
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
> 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
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 no
> > 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 ca
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 var
> 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 subs
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 woul
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 abou
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 nc[16]={4,
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
To
29 matches
Mail list logo
