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: <alpine.DEB.2.00.1105031538470.27795@chino.kir.corp.google.com>
Date:	Tue, 3 May 2011 15:40:47 -0700 (PDT)
From:	David Rientjes <rientjes@...gle.com>
To:	Geert Uytterhoeven <geert@...ux-m68k.org>
cc:	James Bottomley <James.Bottomley@...e.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Pekka Enberg <penberg@...helsinki.fi>,
	Christoph Lameter <cl@...ux.com>, linux-m68k@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [git pull] m68k SLUB fix for 2.6.39

On Fri, 29 Apr 2011, Geert Uytterhoeven wrote:

> My ARAnyM instance has
> 
> System Memory:	276480K
> 	 14 MB at 0x00000000 (ST-RAM)
> 	256 MB at 0x01000000 (alternate RAM)
> 
> and 137800KIB of swap, and survived the following program just fine:
> 
> #include <stdio.h>
> #include <stdlib.h>
> #include <string.h>
> 
> int main(int argc, char *argv[])
> {
>     size_t size = 1048576;
>     size_t total = 0;
>     void *p;
> 
>     while (size) {
> 	p = malloc(size);
> 	if (!p) {
> 	    printf("Failed to allocate %zu bytes\n", size);
> 	    size /= 2;
> 	}
> 	memset(p, 0xaa, size);
> 	total += size;
> 	printf("Using %zu / 0x%zx bytes of memory\n", total, total);
>     }
> 
>     printf("Finished!\n");
>     return 0;
> }
> 
> i.e. the OOM-killer just killed the program after it consumed all
> available virtual
> memory:
> 
> Out of memory: Kill process 1727 (malloctest) score 854 or sacrifice child
> Killed process 1727 (malloctest) total-vm:361160kB, anon-rss:224164kB,
> file-rss:0kB
> malloctest: page allocation failure. order:0, mode:0x84d0
> 
> So SLUB really seems to work now.
> 

So we're in the unfortunate position where slub works fine for some 
architectures with DISCONTIGMEM and not with others.  It seems like the 
problems originating on James' hppa aren't related to slab allocation at 
all, though, so I'm wondering if we should rethink disallowing SLUB as it 
sits in Linus' tree right now for everything that uses DISCONTINGMEM 
without NUMA and not force them to enable CONFIG_BROKEN?

Perhaps change the kconfig entry to only block slub for parisc instead?
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ