linux-kernel - Re: [1/6] make stack size configurable (was: Re: [-mm patch] i386: enable 4k stacks by default)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20070430183223.GL19966@holomorphy.com>
Date:	Mon, 30 Apr 2007 11:32:23 -0700
From:	William Lee Irwin III <wli@...omorphy.com>
To:	Adrian Bunk <bunk@...sta.de>
Cc:	Andi Kleen <andi@...stfloor.org>,
	Christoph Hellwig <hch@...radead.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	David Chinner <dgc@....com>, Zan Lynx <zlynx@....org>,
	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [1/6] make stack size configurable (was: Re: [-mm patch] i386: enable 4k stacks by default)

On Mon, Apr 30, 2007 at 08:25:38PM +0200, Adrian Bunk wrote:
> These are no questions a user should ever see, and it's impossible that 
> a user will be able to choose the right answer - that's an 
> implementation detail, and it has to be set correctly automatically 
> without bothering the user.
> Pro of bigger stacks:
> - kernel developers have to care less about stack usage
> Pros of smaller stacks:
> - less memory usage
> - higher order allocations are more likely to fail with fragmented
>   memory
> We are currently at "works with 8k stacks and without separate IRQ stacks"
> and at "works in most situations with 4k stacks", so nothing > 8k should 
> be required.

freitag mentioned that IRQ stacks should be bootmem allocated, so I
dredged up a series of debug patches I had that did so. This is in no
way intended as a suggestion we should e.g. merge config options as
in 1/6 for 64KB stacks.

This is all sort of meant to be cherrypicked mostly for 5/6's bootmem
allocation of IRQ stacks. Otherwise it's just a set of debug patches
I wrote. 1/6 is merely needed for 5/6 to eventually apply. 5/6 can't
really be used verbatim because it does various handling for vmalloc()
of stacks and depends on the patches in the series prior to it, but
it is something in the way of bootmem allocation of IRQ stacks being
out there already.

-- wli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/