linux-kernel - Re: [patch 5/5] oom: invoke OOM killer from pagefault handler

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: <452F361D.1010306@yahoo.com.au>
Date:	Fri, 13 Oct 2006 16:45:49 +1000
From:	Nick Piggin <nickpiggin@...oo.com.au>
To:	Andrew Morton <akpm@...l.org>
CC:	Nick Piggin <npiggin@...e.de>, Kirill Korotaev <dev@...ru>,
	Linux Memory Management <linux-mm@...ck.org>,
	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [patch 5/5] oom: invoke OOM killer from pagefault handler

Andrew Morton wrote:

>On Thu, 12 Oct 2006 17:19:07 +0200
>Nick Piggin <npiggin@...e.de> wrote:
>
>
>>On Thu, Oct 12, 2006 at 07:12:13PM +0400, Kirill Korotaev wrote:
>>
>>>Nick,
>>>
>>>AFAICS, 1 page allocation which is done in page fault handler
>>>can fail in the only case - OOM kills current, so if we failed
>>>we should have TIF_MEMDIE and just kill current.
>>>Selecting another process for killing if page fault fails means
>>>taking another victim with the one being already killed.
>>>
>>>
>>Hi Kirill,
>>
>>I don't quite understand you.
>>
>
>Kirill is claiming that the only occasion on which a pagefault handler would
>get an oom is when it killed itself in the oom handler.
>

Well I don't think that should happen much. When the process gets OOM 
killed,
it is given full access to all memory reserves, so it will be _less_ likely
to go OOM maybe.

Actually if you work it through, maybe that isn't the case -- our 
infinite retry
logic in the allocator means that non OOM killed tasks will never return 
NULL,
while the OOM task might just use up every single free page in the 
system and
will eventually return NULL. In this case the system is probably on 
death's door
though, so I don't know if it is worth worrying about.

>>If the page allocation fails in the
>>fault handler, we don't want to kill current if it is marked as
>>OOM_DISABLE or sysctl_panic_on_oom is set... imagine a critical
>>service in a failover system.
>>
>>It should be quite likely for another process to be kiled and
>>provide enough memory to keep the system running. Presuming you
>>have faith in the concept of the OOM killer ;)
>>
>
>I'm a bit wobbly about this one.  Some before-and-after testing results
>would help things along..
>

I can force VM_FAULT_OOMs to happen, but it is difficult to make it 
happen in
the real world because most fault handling paths don't allocate higher order
allocations.

What I especially have in mind here is the OOM_DISABLE and panic_on_oom 
sysctl
rather than expecting particularly much better general oom killing 
behaviour.
Suppose you have a critical failover node or heartbeat process or something
where you'd rather the system to panic and reboot instead of doing something
silly...

--

Send instant messages to your online friends http://au.messenger.yahoo.com 
-
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/