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: <20150825142503.GE6285@dhcp22.suse.cz>
Date:	Tue, 25 Aug 2015 16:25:04 +0200
From:	Michal Hocko <mhocko@...nel.org>
To:	David Rientjes <rientjes@...gle.com>
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 Mon 24-08-15 14:04:28, David Rientjes wrote:
> 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.

Why?

> It would be better to reboot when memory reserves are fully depleted.

The question is when are the reserves depleted without any way to
replenish them. While playing with GFP_NOFS patch set which gives
__GFP_NOFAIL allocations access to memory reserves
(http://marc.info/?l=linux-mm&m=143876830916540&w=2) I could see the
warning hit while the system still resurrected from the memory pressure.

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

I think an OOM reserve/watermark makes more sense. It will not solve the
livelock but neithere granting the full access to reserves will. But the
partial access has a potential to leave some others means to intervene.

-- 
Michal Hocko
SUSE Labs
--
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/