linux-kernel - Re: Bug#695182: [RFC] Reproducible OOM with just a few sleeps

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: <1359609334.31386.40.camel@deadeye.wl.decadent.org.uk>
Date:	Thu, 31 Jan 2013 05:15:34 +0000
From:	Ben Hutchings <ben@...adent.org.uk>
To:	paul.szabo@...ney.edu.au, 695182@...s.debian.org
Cc:	dave@...ux.vnet.ibm.com, pavel@....cz,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: Bug#695182: [RFC] Reproducible OOM with just a few sleeps

On Thu, 2013-01-31 at 06:40 +1100, paul.szabo@...ney.edu.au wrote:
> Dear Pavel and Dave,
> 
> > The assertion was that 4GB with no PAE passed a forkbomb test (ooming)
> > while 4GB of RAM with PAE hung, thus _PAE_ is broken.
> 
> Yes, PAE is broken. Still, maybe the above needs slight correction:
> non-PAE HIGHMEM4G passed the "sleep test": no OOM, nothing unexpected;
> whereas PAE OOMed then hung (tested with various RAM from 3GB to 64GB).
> 
> The feeling I get is that amd64 is proposed as a drop-in replacement for
> PAE, that support and development of PAE is gone, that PAE is dead.

PAE was a stop-gap that kept x86-32 alive on servers until x86-64 came
along (though it was supposed to be ia64...).  That's why I was
surprised you were still trying to run a 32-bit kernel.

The fundamental problem with Linux on 32-bit systems for the past ~10
years has been that RAM sizes approached and exceeded the 32-bit virtual
address space and the kernel can't keep it all mapped.

Whenever a task makes a system call the kernel will continue to use the
same virtual memory mappings to access that task's memory, as well as
its own memory.  Which means both of those have to fit within the
virtual address space.  (The alternative of using separate address
spaces is pretty bad for performance - see OS X as an example.  And it
only helps you as far as 4GB RAM.)

The usual split on 32-bit machines is 3GB virtual address space for each
task and 1GB for the kernel.  Part of that 1GB is reserved for memory-
mapped I/O and temporary mappings, and the rest is mapped to the
beginning of RAM (lowmem).  All the remainder of RAM is highmem,
available for allocation by tasks but not for the kernel's private data
(in general).

Switching to PAE does not change the amount of lowmem, but it does make
hardware page table entries (which of course live in lowmem) twice as
big.  This increases the pressure on lowmem a little, which probably
explains the negative result of your 'sleep test'.  However if you then
try to take full advantage of the 64GB range of PAE, as you saw earlier,
the shortage of lowmem relative to highmem becomes completely untenable.

Ben.

-- 
Ben Hutchings
If more than one person is responsible for a bug, no one is at fault.

Download attachment "signature.asc" of type "application/pgp-signature" (829 bytes)