linux-kernel - Re: [PATCH] oom: add sysctl to enable slab memory dump

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.1202240200380.24971@chino.kir.corp.google.com>
Date:	Fri, 24 Feb 2012 02:03:49 -0800 (PST)
From:	David Rientjes <rientjes@...gle.com>
To:	Pekka Enberg <penberg@...nel.org>
cc:	Rafael Aquini <aquini@...hat.com>, linux-mm@...ck.org,
	Randy Dunlap <rdunlap@...otime.net>,
	Christoph Lameter <cl@...ux-foundation.org>,
	Matt Mackall <mpm@...enic.com>, Rik van Riel <riel@...hat.com>,
	Josef Bacik <josef@...hat.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] oom: add sysctl to enable slab memory dump

On Fri, 24 Feb 2012, Pekka Enberg wrote:

> Right. We should drop the sysctl and make it into a kernel command line 
> debugging option instead.
> 

I like how slub handles this when it can't allocate more slab with 
slab_out_of_memory() and has the added benefit of still warning even with 
__GFP_NORETRY that the oom killer is never called for.  If there's really 
a slab leak happening, there's a good chance that this diagnostic 
information is going to be emitted by the offending cache at some point in 
time if you're using slub.  This could easily be extended to slab.c, so 
it's even more reason not to include this type of information in the oom 
killer.
--
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/