From: "Jörn Engel" <joern@wohnheim.fh-wedel.de>
To: John Bradford <john@grabjohn.com>
Cc: junkio@cox.net, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Port SquashFS to 2.6
Date: Tue, 22 Jul 2003 12:47:23 +0200 [thread overview]
Message-ID: <20030722104723.GE29430@wohnheim.fh-wedel.de> (raw)
In-Reply-To: <200307221036.h6MAa7ER001757@81-2-122-30.bradfords.org.uk>
On Tue, 22 July 2003 11:36:07 +0100, John Bradford wrote:
>
> > If you look closely at the kernel, there is currently no way of
> > telling whether it contains stack overflows waiting to happen, or not.
>
> It would be an interesting experiment to deliberately make the kernel
> stack smaller, and see what happens. If no problems seem apparent
> with a reduced kernel stack, it gives more weight to the argument that
> the default one is OK.
Been there, done that. :)
Use the patch below, enable the stack checking in your .config and
watch the system log get filled. 5k is quite agressive, I agree, but
with 4k stacks in mind, it is just 1k of slack left, plus the
measurement is a bit fuzzy, so you really want some slack.
Maybe there is also a patch flying around that initializes the stack
with some magic number on a fork and logs the number of used bytes on
exit. That way you get rid of the fuzzyness, but you loose the exact
call trace that led to this number.
Jörn
--
Measure. Don't tune for speed until you've measured, and even then
don't unless one part of the code overwhelms the rest.
-- Rob Pike
--- linux-2.5.67/arch/i386/kernel/irq.c~stack_overflow 2003-04-07 19:30:39.000000000 +0200
+++ linux-2.5.67/arch/i386/kernel/irq.c 2003-04-14 20:22:01.000000000 +0200
@@ -342,7 +342,15 @@
__asm__ __volatile__("andl %%esp,%0" :
"=r" (esp) : "0" (8191));
+#if 0
if (unlikely(esp < (sizeof(struct thread_info) + 1024))) {
+#else
+ /* We check for 5k for now. The kernel stack still is 8k,
+ * but should shrink to 4k, so this test makes sense.
+ * Once the stack is 4k, we go back to the old test.
+ */
+ if (unlikely(esp < (sizeof(struct thread_info) + 5120))) {
+#endif
printk("do_IRQ: stack overflow: %ld\n",
esp - sizeof(struct thread_info));
dump_stack();
next prev parent reply other threads:[~2003-07-22 10:32 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-07-22 10:36 John Bradford
2003-07-22 10:47 ` Jörn Engel [this message]
[not found] <fa.k0do8p6.ch6pps@ifi.uio.no>
[not found] ` <fa.hre90bn.e6k5pf@ifi.uio.no>
2003-07-22 2:52 ` junkio
2003-07-22 3:42 ` Valdis.Kletnieks
2003-07-22 10:20 ` Jörn Engel
2003-07-22 10:16 ` Jörn Engel
-- strict thread matches above, loose matches on Subject: below --
2003-07-19 22:59 junkio
2003-07-19 23:35 ` David Dillow
2003-07-20 5:40 ` junkio
2003-07-20 8:22 ` Jörn Engel
2003-07-20 10:16 ` postmaster
2003-07-20 10:38 ` Jörn Engel
2003-07-20 1:50 ` Bernd Eckenfels
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=20030722104723.GE29430@wohnheim.fh-wedel.de \
--to=joern@wohnheim.fh-wedel.de \
--cc=john@grabjohn.com \
--cc=junkio@cox.net \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®