linux-kernel - Re: [patch -mm] mm, oom: add global access to memory reserves on livelock

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.10.1508241358230.32561@chino.kir.corp.google.com>
Date:	Mon, 24 Aug 2015 14:04:28 -0700 (PDT)
From:	David Rientjes <rientjes@...gle.com>
To:	Michal Hocko <mhocko@...nel.org>
cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Mel Gorman <mgorman@...e.de>,
	Johannes Weiner <hannes@...xchg.org>,
	Oleg Nesterov <oleg@...hat.com>,
	Vlastimil Babka <vbabka@...e.cz>, linux-kernel@...r.kernel.org,
	linux-mm@...ck.org,
	Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
Subject: Re: [patch -mm] mm, oom: add global access to memory reserves on
 livelock

On Fri, 21 Aug 2015, Michal Hocko wrote:

> There might be many threads waiting for the allocation and this can lead
> to quick oom reserves depletion without releasing resources which are
> holding back the oom victim. As Tetsuo has shown, such a load can be
> generated from the userspace without root privileges so it is much
> easier to make the system _completely_ unusable with this patch. Not that
> having an OOM deadlock would be great but you still have emergency tools
> like sysrq triggered OOM killer to attempt to sort the situation out.
> Once your are out of reserves nothing will help you, though. So I think it
> is a bad idea to give access to reserves without any throttling.
> 

I don't believe a solution that requires admin intervention is 
maintainable.  It would be better to reboot when memory reserves are fully 
depleted.

> Johannes' idea to give a partial access to memory reserves to the task
> which has invoked the OOM killer was much better IMO.

That's what this patch does, just without the "partial."  Processes are 
required to reclaim and then invoke the oom killler every time an 
allocation is made using memory reserves with this approach after the 
expiration has lapsed.

We can discuss only allowing partial access to memory reserves equal to 
ALLOC_HARD | ALLOC_HARDER, or defining a new watermark, but I'm concerned 
about what happens when that threshold is reached and the oom killer is 
still livelocked.  It would seem better to attempt recovery at whatever 
cost and then panic if fully depleted.
--
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/