linux-kernel - Re: [patch -rc] oom: always return a badness score of non-zero for eligible tasks

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]

Date:	Thu, 9 Sep 2010 14:00:54 -0700 (PDT)
From:	David Rientjes <rientjes@...gle.com>
To:	Dave Hansen <dave@...ux.vnet.ibm.com>
cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Nitin Gupta <ngupta@...are.org>,
	Pekka Enberg <penberg@...helsinki.fi>,
	Minchan Kim <minchan.kim@...il.com>, Greg KH <greg@...ah.com>,
	Linux Driver Project <devel@...verdev.osuosl.org>,
	linux-mm <linux-mm@...ck.org>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [patch -rc] oom: always return a badness score of non-zero for
 eligible tasks

On Thu, 9 Sep 2010, Dave Hansen wrote:

> > I'm curious why there are no killable processes on the system; it seems 
> > like the triggering task here, cat, would at least be killable itself.  
> > Could you post the tasklist dump that preceeds this (or, if you've 
> > disabled it try echo 1 > /proc/sys/vm/oom_dump_tasks first)?
> 
> That was one odd part here.  I didn't disable the tasklist dump, and
> there was none in the dump.
> 

Hmm, could you very that /proc/sys/vm/oom_dump_tasks is set?  Perhaps it's 
getting cleared by something else before you use zram.  The sysctl should 
default to on as of 2.6.36-rc1.

> > It's possible that if you have enough swap that none of the eligible tasks 
> > actually have non-zero badness scores either because they are being run as 
> > root or because the amount of RAM or swap is sufficiently high such that 
> > (task's rss + swap) / (total rss + swap) is never non-zero.  And, since 
> > root tasks have a 3% bonus, it's possible these are all root tasks and no 
> > single task uses more than 3% of rss and swap.
> 
> It's a 64GB machine with ~30GB of swap and very little RSS.  Your
> hypothesis seems correct.  Just grepping through /proc/[0-9]*/oom_score
> shows nothing other than 0's.
> 

Presumably you're not using a large amount of swap, either, or that would 
be accounted for in oom_score.

> Trying this again, I just hung the system instead of OOM'ing straight
> away like last time.
> 

with the patch, you should still be calling the oom killer and instead of 
panicking it will go on a serial killing spree because everything that it 
wasn't judging as a candidate before (oom_score of 0) now is if it's truly 
killable (oom_score of 1).  The patch is definitely needed for correctness 
since an oom_score of 0 implies the task is unkillable.

We're apparently hanging in the exit path for the oom killed task or 
something is constantly respawning threads that repeatedly get killed.  It 
appears as though nothing is actually a worthwhile target for the oom 
killer, however, and this is a bad configuration.

> Your patch makes a lot of sense to me in any case where there aren't
> large-RSS tasks around using memory.  That definitely applies here
> because of the amount in the compcache store and might also apply with
> ramfs and hugetlbfs.
> 

Agreed, we'll need to address hugepages specifically because they don't 
get accounted for in rss but do free memory when the task is killed.
--
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/