linux-kernel - "heuristic overcommit" and fork()

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: <ED3886372DB5491AAA799709DBA78F6F@david>
Date:	Wed, 11 Feb 2009 20:26:32 +0100
From:	"David CHAMPELOVIER" <david@...mpelovier.com>
To:	<linux-kernel@...r.kernel.org>
Subject: "heuristic overcommit" and fork()

Hi,

Recently, I was unable to fork() a 38 GB process on a system with 64 GB RAM
and no swap.
Having a look at the kernel source, I surprisingly found that in "heuristic
overcommit" mode, fork() always checks that there is enough memory to
duplicate process memory.

As far as I know, overcommit was introduced in the kernel for several
reasons, and fork() was one of them, since applications often exec() just
after fork(). I know fork() is not the most judicious choice in this case,
but well, this is the way many applications are written.

Moreover, I can read in the proc man page that in "heuristic overcommit
mode", "obvious overcommits of address space are refused". I do not think
fork() is an obvious overcommit, that's why I would expect fork() to be
always accepted in this mode.

So, is there a reason why fork() checks for available memory in "heuristic
mode" ?

Thanks in advance.

--
David Champelovier

--
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/