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

On Thu, 23 Feb 2012, Josef Bacik wrote:

> I requested this specifically because I was oom'ing the box so hard that I
> couldn't read /proc/slabinfo at the time of OOM and therefore had no idea what I
> was leaking.  Telling me how much slab was in use was no help, I needed to know
> which of the like 6 objects I was doing horrible things with was screwing me,
> and without this patch I would have no way of knowing.
> 

So an oom was creating a denial of service so that you had no way to do 
cat /proc/slabinfo?  I think we should talk about this first, because 
that's a serious situation that certainly shouldn't be happening.

The oom killer is designed to kill the most memory-hogging task available 
so that it doesn't have to kill multiple threads.  Why was the memory not 
being freed or why was the thread that was consistently being killed 
restarted time and time again so you couldn't even cat a file?

> Sure, if the OOM killer doesn't kill the poller, or kill NetworkManager since
> I'm remote logged into the box, or any of the other various important things
> that would be required for me to get this info.  Thanks,
> 

If you're polling for oom notifications sanely, you'd probably have set

	echo -1000 > /proc/pid/oom_score_adj

so it's unkillable as well as anything else you need to diagnose failures.  
NetworkManager itself isn't protected like this by default, but it 
shouldn't be killed unless it is leaking memory itself: we kill in the 
order of the most memory usage to the least.

So neither of these are reasons to not collect /proc/slabinfo, but I'm 
very interested in your follow-up to why you can't do so when "ooming the 
box so hard" where you're presumably able to cat to kernel log file but 
not cat /proc/slabinfo :)
--
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/