linux-kernel - 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-next>] [day] [month] [year] [list]

Message-ID: <20070313163320.GA28104@localdomain>
Date:	Tue, 13 Mar 2007 18:33:20 +0200
From:	Dan Aloni <da-x@...atomic.org>
To:	Linux Kernel List <linux-kernel@...r.kernel.org>
Subject: thread stacks and strict vm overcommit accounting

Hello,

This question is relevent to 2.6.20.

I noticed that if the RSS for the stack size is say, 8MB, running
a single-threaded process doesn't incur an increase of 8MB to
Committed_AS (/proc/meminfo).

However, on multi-threaded apps linked with pthread (on Debian
Etch with 2.6.20 vanilla x86_64), every thread will incur the
the specified maximum stack size RSS (assuming that you use
the default attr). In other words, it appears that vm accounting
works differently in that case.

Is this the intended behaviour?

-- 
Dan Aloni
XIV LTD, http://www.xivstorage.com
da-x (at) monatomic.org, dan (at) xiv.co.il
-
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/