linux-kernel - Re: running of out memory => kernel crash

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:	Fri, 19 Aug 2011 00:25:27 +0200
From:	Denys Vlasenko <vda.linux@...glemail.com>
To:	Pavel Ivanov <paivanof@...il.com>
Cc:	Mahmood Naderan <nt_mahmood@...oo.com>,
	David Rientjes <rientjes@...gle.com>,
	Randy Dunlap <rdunlap@...otime.net>,
	"\"linux-kernel@...r.kernel.org\"" <linux-kernel@...r.kernel.org>,
	"\"linux-mm@...ck.org\"" <linux-mm@...ck.org>
Subject: Re: running of out memory => kernel crash

On Thursday 18 August 2011 16:26, Pavel Ivanov wrote:
> On Thu, Aug 18, 2011 at 8:44 AM, Denys Vlasenko
> <vda.linux@...glemail.com> wrote:
> >> I have a little concern about this explanation of yours. Suppose we
> >> have some amount of more or less actively executing processes in the
> >> system. Suppose they started to use lots of resident memory. Amount of
> >> memory they use is less than total available physical memory but when
> >> we add total size of code for those processes it would be several
> >> pages more than total size of physical memory. As I understood from
> >> your explanation in such situation one process will execute its time
> >> slice, kernel will switch to other one, find that its code was pushed
> >> out of RAM, read it from disk, execute its time slice, switch to next
> >> process, read its code from disk, execute and so on. So system will be
> >> virtually unusable because of constantly reading from disk just to
> >> execute next small piece of code. But oom will never be firing in such
> >> situation. Is my understanding correct?
> >
> > Yes.
> >
> >> Shouldn't it be considered as an unwanted behavior?
> >
> > Yes. But all alternatives (such as killing some process) seem to be worse.
> 
> Could you elaborate on this? We have a completely unusable server
> which can be revived only by hard power cycling (administrators won't
> be able to log in because sshd and shell will fall victims of the same
> unending disk reading).

You can ssh into it. It will just take VERY, VERY LONG.

> And as an alternative we can kill some process 
> and at least allow administrator to log in and check if something else
> can be done to make server feel better. Why is it worse?
> 
> I understand that it could be very hard to detect such situation

Exactly. Server has no means to know when the situation is
bad enough to start killing. IIRC now the rule is simple:
OOM killing starts only when allocations fail.

Perhaps it is possible to add "start OOM killing if less than N free
pages are available", but this will be complex, and won't be good enough
for some configs with many zones (thus, will require even more complications).

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