All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brian Gerst <bgerst@didntduck.org>
To: Andi Kleen <ak@suse.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [CHECKER] large stack variables (>=1K) in 2.4.4 and 2.4.4-ac8
Date: Fri, 25 May 2001 08:07:40 -0400	[thread overview]
Message-ID: <3B0E4B0C.C5F3218F@didntduck.org> (raw)
In-Reply-To: <200105242110.OAA29766@csl.Stanford.EDU> <200105242308.f4ON8fv8015978@webber.adilger.int> <20010525013303.A21810@gruyere.muc.suse.de> <3B0E4762.7A7A3818@didntduck.org> <20010525135317.B29643@gruyere.muc.suse.de>

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 the
> > kernel tries to use the task struct.  There are only two ways to
> > properly trap a kernel stack overflow:
> 
> In my experience the stack pointer eventually gets corrupted and starts
> pointing to some unmapped area, which gives you a stack fault (admittedly
> a backtrace is a bit hard after that)

You mean a double fault.  #SS is only called when there is a limit
violation on the stack segment or the stack segment is not present.  I
guess you could get a limit violation if it tried to wrap around below
0, but you would get a page fault first.  An unmapped page will always
cause a page fault, but since the stack is still invalid, it would then
cause a double fault.

-- 

						Brian Gerst

  reply	other threads:[~2001-05-25 12:07 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-05-24 21:10 [CHECKER] large stack variables (>=1K) in 2.4.4 and 2.4.4-ac8 Dawson Engler
2001-05-24 22:40 ` Anton Altaparmakov
2001-05-24 23:08 ` Andreas Dilger
2001-05-24 23:33   ` Andi Kleen
2001-05-25  5:20     ` Keith Owens
2001-05-25  6:33       ` Andreas Dilger
2001-05-25  6:53         ` Keith Owens
2001-05-25  8:20           ` Andi Kleen
2001-05-25  8:31             ` Keith Owens
2001-05-25  8:39               ` Andi Kleen
2001-05-25 14:03           ` Oliver Neukum
2001-05-25 14:07             ` Andi Kleen
2001-05-25 15:45               ` dean gaudet
2001-05-25 16:34                 ` Jonathan Lundell
2001-05-25 18:37                   ` dean gaudet
2001-05-25 17:49                     ` Jeff Dike
2001-05-25  7:11       ` David Welch
2001-05-25  8:08         ` Keith Owens
2001-05-25 15:31         ` dean gaudet
2001-05-25 15:49           ` Keith Owens
2001-05-25 18:46             ` dean gaudet
2001-05-25  8:14       ` Andi Kleen
2001-05-25  8:25         ` Keith Owens
2001-05-25  8:27           ` Andi Kleen
2001-05-25  8:37             ` Keith Owens
2001-05-25  8:17       ` Andi Kleen
2001-05-25 11:52     ` Brian Gerst
2001-05-25 11:53       ` Andi Kleen
2001-05-25 12:07         ` Brian Gerst [this message]
2001-05-25  3:38   ` Andrew Morton
  -- strict thread matches above, loose matches on Subject: below --
2001-05-24 23:01 Mikael Pettersson
2001-05-25  2:48 ` Dawson Engler
2001-05-25  3:00   ` Alexander Viro
2001-05-25  3:07     ` Dawson Engler
2001-05-25  4:23 Dunlap, Randy
2001-07-03  9:15 VDA

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3B0E4B0C.C5F3218F@didntduck.org \
    --to=bgerst@didntduck.org \
    --cc=ak@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.