linux-kernel - Re: [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: <50F4A92F.2070204@linux.vnet.ibm.com>
Date:	Mon, 14 Jan 2013 16:56:15 -0800
From:	Dave Hansen <dave@...ux.vnet.ibm.com>
To:	paul.szabo@...ney.edu.au
CC:	695182@...s.debian.org, linux-kernel@...r.kernel.org,
	linux-mm@...ck.org
Subject: Re: [RFC] Reproducible OOM with just a few sleeps

On 01/14/2013 12:36 PM, paul.szabo@...ney.edu.au wrote:
> I understand that more RAM leaves less lowmem. What is unacceptable is
> that PAE crashes or freezes with OOM: it should gracefully handle the
> issue. Noting that (for a machine with 4GB or under) PAE fails where the
> HIGHMEM4G kernel succeeds and survives.

You have found a delta, but you're not really making apples-to-apples
comparisons.  The page tables (a huge consumer of lowmem in your bug
reports) have much more overhead on a PAE kernel.  A process with a
single page faulted in with PAE will take at least 4 pagetable pages
(it's 7 in practice for me with sleeps).  It's 2 pages minimum (and in
practice with sleeps) on HIGHMEM4G.

There's probably a bug here.  But, it's incredibly unlikely to be seen
in practice on anything resembling a modern system.  The 'sleep' issue
is easily worked around by upgrading to a 64-bit kernel, or using sane
ulimit values.  Raising the vm.min_free_kbytes sysctl (to perhaps 10x of
its current value on your system) is likely to help the hangs too,
although it will further "consume" lowmem.

I appreciate your persistence here, but for a bug with such a specific
use case, and with so many reasonable workarounds, it's not something I
want to dig in to much deeper.  I'll be happy to answer any questions if
you want to go digging deeper, or want some pointers on where to go
looking to fix this properly.

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