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: <20150821081745.GG23723@dhcp22.suse.cz>
Date:	Fri, 21 Aug 2015 10:17:45 +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

[CCing Tetsuo - he was really concerned about the oom deadlocks and he
 was proposing a timeout based solution as well]

On Thu 20-08-15 14:00:36, David Rientjes wrote:
> On system oom, a process may fail to exit if its thread depends on a lock
> held by another allocating process.
> 
> In this case, we can detect an oom kill livelock that requires memory
> allocation to be successful to resolve.
> 
> This patch introduces an oom expiration, set to 5s, that defines how long
> a thread has to exit after being oom killed.
> 
> When this period elapses, it is assumed that the thread cannot make
> forward progress without help.  The only help the VM may provide is to
> allow pending allocations to succeed, so it grants all allocators access
> to memory reserves after reclaim and compaction have failed.

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.

Johannes' idea to give a partial access to memory reserves to the task
which has invoked the OOM killer was much better IMO.
-- 
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/