All of lore.kernel.org
 help / color / mirror / Atom feed
From: Adrian Bunk <bunk@stusta.de>
To: Mike Snitzer <snitzer@gmail.com>
Cc: Mark Lord <lkml@rtr.ca>, "J.A. Magallon" <jamagallon@able.es>,
	"Linux-Kernel," <linux-kernel@vger.kernel.org>,
	mpm@selenic.com
Subject: Re: About 4k kernel stack size....
Date: Tue, 20 Dec 2005 16:00:34 +0100	[thread overview]
Message-ID: <20051220150033.GF6789@stusta.de> (raw)
In-Reply-To: <170fa0d20512200637l169654c9vbe38c9931c23dfb1@mail.gmail.com>

On Tue, Dec 20, 2005 at 09:37:28AM -0500, Mike Snitzer wrote:
> On 12/20/05, Adrian Bunk <bunk@stusta.de> wrote:
> > On Mon, Dec 19, 2005 at 09:52:53PM -0500, Mark Lord wrote:
> > >...
> > > The mainline code paths are undoubtedly fine with 4K stacks.
> > > It's the *error paths* that are most likely to go deeper on the stack,
> > > and those are rarely exercised by anyone.  And those are the paths
> > > that we *really* need to be reliable.
> >
> > "most likely" is a strong sentence, especially considering that the
> > automatic analysis of all possible call chains can and has already
> > identified several such problems (which have now been fixed many months
> > ago).
> >
> > We might not getting 100% security against stack overflows, but that's
> > not fundamentally different from the current situation with 6 kB stacks.
> 
> Given this last statement, why is it that Matt Mackall's suggestion in
> the "Light-weight dynamically extended stacks" thread didn't get any
> _real_ discussion from the big 4K stack advocates?  For all intents
> and purposes, Matt was dismissed with the same Bunk: "Ever since
> neilb's patch there are 0 bugs.. blah blah".  4K, 8K (aka "6 kB")
> aside; having more stack safety in the Linux kernel is a "good thing"
> no?  Aren't dynamic stacks a viable means to imposing 4K (but doing so
> with real safety)?

Besides the fact that I still don't think it's requred, Matt's 
suggestion would work only randomly for functions using more than 1 kB 
stack.

But discussing hypothetical patches is silly - code talks.

If someone sends a patch implementing Mark's suggestion and it gets 
measured that this patch doesn't impose a performance penalty we'd
have a basis for a real discussion.

> Mike

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed


  reply	other threads:[~2005-12-20 15:00 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-18 22:14 About 4k kernel stack size J.A. Magallon
2005-12-20  2:52 ` Mark Lord
2005-12-20 13:37   ` Adrian Bunk
2005-12-20 14:37     ` Mike Snitzer
2005-12-20 15:00       ` Adrian Bunk [this message]
2005-12-20 15:55       ` Sean
2005-12-20 15:55         ` Sean
2005-12-21 15:07           ` Giridhar Pemmasani
2005-12-21 15:37             ` Kyle Moffett
2005-12-21 16:25               ` Giridhar Pemmasani
2005-12-21 16:46             ` Christoph Hellwig
2005-12-21 20:14             ` Krzysztof Halasa
2005-12-21 21:39               ` linux-os (Dick Johnson)
2005-12-22  9:14             ` Romano Giannetti
2005-12-20 17:02         ` linux-os (Dick Johnson)
2005-12-20 18:06           ` Chase Venters
2005-12-20 18:36             ` linux-os (Dick Johnson)
2005-12-20 18:43               ` Arjan van de Ven
2005-12-20 18:59                 ` linux-os (Dick Johnson)
2005-12-20 22:33                 ` Alan Cox
2005-12-20 22:54           ` Nikita Danilov
2005-12-21 14:02             ` linux-os (Dick Johnson)
2005-12-21 14:18               ` Nikita Danilov
2005-12-21 14:25                 ` linux-os (Dick Johnson)
2005-12-21 15:19                   ` Nikita Danilov
2005-12-21 22:50                     ` Jan Engelhardt
2005-12-20 20:15   ` Alan Cox

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=20051220150033.GF6789@stusta.de \
    --to=bunk@stusta.de \
    --cc=jamagallon@able.es \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkml@rtr.ca \
    --cc=mpm@selenic.com \
    --cc=snitzer@gmail.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.