Comment 6 for bug 159356

I'm pretty sure this is the same but as reported in BUG #283420.

There is a very small, very simple C++ utility posted on that thread that can be used to reproduce the system.

The steps to reproduce are:

1. compile the binary: "g++ memory_overcommit.cc -o memory_overcommit.bin"

2. Start "top" (or any other utility that displays memory/swap/cache usage) and switch to memory centered view (key "M", i.e. uppercase M).

2. run the compiled binary: ./memory_overcommit.bin

3. Eat up the memory using the tool. You can start with chunks of (a few) hundred MiB, but - this is important - when approaching the value of free memory (i.e. when the free memory is reduced to smaller amounts) reduce the chunk size and /slowly/ approach the limit and wait a few seconds between each chunk of a few tens fo MiB. If the memory is allocated in too big chunks, the process gets killed correctly by the kernel OOM-killer (usually after a system stall of several seconds)!

This bug can be observed especially when slowly approaching the hard limit of system memory, and with slow SWAP media (notably encrypted swap).

IMO, this is even a security-issue, because it allows a total DOS in a multiuser environment.
Has anyone observed the Linux kernel mailinglist (LKML) above this matter?

Link to C++ utility (see other bug report):
http://launchpadlibrarian.net/23372552/memory_overcommit.cc