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 11:41:43 +0200 [thread overview]
Message-ID: <200605311141.43340.ak@suse.de> (raw)
In-Reply-To: <1149064749.26542.191.camel@piet2.bluelane.com>
> My bet is that in this case I was storing a LOT of
> data in the thread structure, so the space left for
> the stack was massively reduced.
Ok so it was your bug. Don't do that.
> Sure but the debugger environment must tolerate larger stacks.
No, Linux doesn't tolerate larger stacks.
> But this can miss a minor abuse. The interrupt check
> is a quick and simple hack but I wonder if it's really
> optimal for commercial implementations.
In practice if you overwrite thread_info you crash eventually
and it's noticed. If you write below thread_info but keep
ti intact then the redzone would likely not catch it either.
I don't think an additional red zone would improve overflow detection
in a significant way.
> I think all modules should be ABLE to be built in.
If you have a working module it can be easily built in too.
Just hacks that don't work with modules are bad.
-Andi
next prev parent reply other threads:[~2006-05-31 9:41 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
2006-05-31 8:39 ` Piet Delaney
2006-05-31 9:41 ` Andi Kleen [this message]
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=200605311141.43340.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 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.