public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@suse.de>
To: piet@bluelane.com
Cc: "Amit S. Kale" <amitkale@linsyssoft.com>,
	"Vladimir A. Barinov" <vbarinov@ru.mvista.com>,
	Andrew Morton <akpm@osdl.org>,
	kgdb-bugreport@lists.sourceforge.net, trini@kernel.crashing.org,
	linux-kernel@vger.kernel.org
Subject: Re: linux-2.6 x86_64 kgdb issue
Date: Wed, 31 May 2006 09:13:53 +0200	[thread overview]
Message-ID: <200605310913.54758.ak@suse.de> (raw)
In-Reply-To: <1149057987.26542.116.camel@piet2.bluelane.com>

On Wednesday 31 May 2006 08:46, Piet Delaney wrote:
> On Wed, 2006-05-31 at 07:50 +0200, Andi Kleen wrote:
> > > Perhaps we should add a kgdb config menu option and #define
> > > CONFIG_16KSTACKS to double the stack size so the kernel can be 
> > > debugged with more context available. I'm currently using -O0 for 
> > > the networking stack and -O1 for the rest of the kernel. Sounds like 
> > > it would be helpful now for AMD64 targets.
> > 
> > You only got stack overflows when working with kgdb right?
> 
> Yes, I was using kgdb to look at the stack audits I stored in
> the thread structure.

Again this likely points to kgdb using too much stack.

  
> > Sounds like a kgdb problem to me then that can and should be probably fixed. e.g. 
> > afaik kgdb isn't reentrant anyways so it could just use static buffers.
> 
> On Solaris the problem was that the kernel stack was larger because tail
> optimization was disabled with optimization disabled. I'm not having
> a kgdb problem with i386, it seems that Vladimir is/was and Amit
> suspected it being due to the AMD64 requiring largers stacks. Seems
> plausible to me. I thought you might have thoughts on that.

Stack usage in Linux isn't that tight that it should make a difference.
If something needs too much stack we just fix it.
 
> > 
> > I would suggest against adding any new config options for this - it would
> > conflict with the great goal of having loadable debuggers that work
> > on any kernels.
> 
> What's the conflict with larger kernel stacks and a loadable (kgdb)
> module? 

We'll not increase the stacks by default but the debugger should
work anyways.

> I was suggesting larger stack space for the kernel, not kgdb. I agree
> this case might be one where kgdb has caused the kernel to trip over 
> the edge. I don't feel comfortable running on a kernel that running
> that close to running out of stack space. Maybe that's just a personal
> preference; I'm paranoid I guess. I like having rock solid systems and
> wacking the stack isn't always detected. On SunOS we had a REDZONE but
> last I check Linux didn't; has one been added? 

Interrupts can check for too much stack space used.

> If it hasn't it might 
> be good to keep in mind having a CPU specific physical page available
> when we grow into the REDZONE. Looked to me like the stack grows right
> into the thread structure; might make a nice exploit for a linux root
> kit.

If you have a stack overflow you usually have other problems than that.

> Having loadable debuggers seems a bit high hopes, as 'we' haven't even
> release linux with kgdb built into the Linux src yet. 

Yes because you if modular works you don't need to build it in.

Modular was working at some point on x86-64 for kdb and the original 2.6 version
of kgdb was nearly there too.
 
-Andi


  reply	other threads:[~2006-05-31  7:14 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <446E0B4B.9070003@ru.mvista.com>
     [not found] ` <200605241240.05313.amitkale@linsyssoft.com>
     [not found]   ` <4474A1D0.30807@ru.mvista.com>
     [not found]     ` <200605251207.27699.amitkale@linsyssoft.com>
2006-05-31  4:45       ` linux-2.6 x86_64 kgdb issue Piet Delaney
2006-05-31  5:50         ` Andi Kleen
2006-05-31  6:46           ` Piet Delaney
2006-05-31  7:13             ` Andi Kleen [this message]
2006-05-31  8:39               ` Piet Delaney
2006-05-31  9:41                 ` Andi Kleen
2006-05-31 15:03               ` Tom Rini
2006-05-31 21:01                 ` Andi Kleen
2006-05-31 22:35                   ` Tom Rini
2006-05-31 22:59                     ` Andi Kleen
2006-05-31 22:52                   ` Piet Delaney
2006-05-31 23:03                     ` Piet Delaney

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=200605310913.54758.ak@suse.de \
    --to=ak@suse.de \
    --cc=akpm@osdl.org \
    --cc=amitkale@linsyssoft.com \
    --cc=kgdb-bugreport@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=piet@bluelane.com \
    --cc=trini@kernel.crashing.org \
    --cc=vbarinov@ru.mvista.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox