linux-kernel - Re: thread stacks and strict vm overcommit accounting

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: <a36005b50703151359r3aa951dbtfedda605c0966ff1@mail.gmail.com>
Date:	Thu, 15 Mar 2007 12:59:09 -0800
From:	"Ulrich Drepper" <drepper@...il.com>
To:	"Hugh Dickins" <hugh@...itas.com>
Cc:	"Andrew Morton" <akpm@...ux-foundation.org>,
	"Dan Aloni" <da-x@...atomic.org>, linux-kernel@...r.kernel.org
Subject: Re: thread stacks and strict vm overcommit accounting

On 3/15/07, Hugh Dickins <hugh@...itas.com> wrote:
> I'm guessing that the pthread stacks are mmap'ed as greatest extents
> (probably because that's the easiest way to keep them apart), rather
> than as small MAP_GROWSDOWN areas to be expanded later on fault.

Please all, forget about MAP_GROWSDOWN.  It's useless.  If thread
stacks are not completely mapped (address space allocation, memory
allocation is not needed) it means subsequent unrelated mmaps can fall
into the address space which is meant to be used for the stack, hence
preventing the stack from growing.

libpthread uses an mmap for the complete stack size all the time and
this of course is accounted for in the kernel.
-
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/