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, 09 Sep 2010 12:48:03 -0700
From:	Dave Hansen <dave@...ux.vnet.ibm.com>
To:	David Rientjes <rientjes@...gle.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, 2010-09-09 at 12:07 -0700, David Rientjes wrote:
> On Thu, 9 Sep 2010, Dave Hansen wrote:
> 
> > Hi Nitin,
> > 
> > I've been playing with using zram (from -staging) to back some qemu
> > guest memory directly.  Basically mmap()'ing the device in instead of
> > using anonymous memory.  The old code with the backing swap devices
> > seemed to work pretty well, but I'm running into a problem with the new
> > code.
> > 
> > I have plenty of swap on the system, and I'd been running with compcache
> > nicely for a while.  But, I went to go tar up (and gzip) a pretty large
> > directory in my qemu guest.  It panic'd the qemu host system:
> > 
> > [703826.003126] Kernel panic - not syncing: Out of memory and no killable processes...
> > [703826.003127] 
> > [703826.012350] Pid: 25508, comm: cat Not tainted 2.6.36-rc3-00114-g9b9913d #29
> 
> 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.

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

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

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.

-- Dave

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