linux-kernel - Re: [PATCH] oom: always panic on OOM when panic_on

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.1506081252050.13272@chino.kir.corp.google.com>
Date:	Mon, 8 Jun 2015 12:58:45 -0700 (PDT)
From:	David Rientjes <rientjes@...gle.com>
To:	Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
cc:	mhocko@...e.cz, akpm@...ux-foundation.org, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] oom: always panic on OOM when panic_on_oom is
 configured

On Sat, 6 Jun 2015, Tetsuo Handa wrote:

> For me, !__GFP_FS allocations not calling out_of_memory() _forever_ is a
> violation of the user policy.
> 

I agree that we need work in this area to prevent livelocks that rely on 
the contexts of other allocators to make forward progress, but let's be 
clear that panicking the system is not the appropriate response.  It's 
nice and convenient to say we should repurpose panic_on_oom to solve 
livelocks because it triggers a fast reboot in your configuration, but we, 
and certainly others, can't tolerate reboots when the kernel just gives up 
and the majority of the time these situations do resolve themselves.

I think the appropriate place to be attacking this problem is in the page 
allocator, which is responsible for the page allocations in the context of 
the gfp flags given to it, and not the oom killer.  The oom killer is just 
supposed to pick a process, send it a SIGKILL, and give it a reasonable 
expectation of being able to exit.

> If kswapd found nothing more to reclaim and/or kswapd cannot continue
> reclaiming due to lock dependency, can't we consider as out of memory
> because we already tried to reclaim memory which would have been done by
> __GFP_FS allocations?
> 
> Why do we do "!__GFP_FS allocations do not call out_of_memory() because
> they have very limited reclaim ability"? Both GFP_NOFS and GFP_NOIO
> allocations will wake up kswapd due to !__GFP_NO_KSWAPD, doesn't it?
> 

The !__GFP_FS exception is historic because the oom killer would trigger 
waaay too often if it were removed simply because it doesn't have a great 
chance of allowing reclaim to succeed.  Instead, we rely on external 
memory freeing or other parallel allocators being able to reclaim memory.  
What happens when there is no external freeing, nothing else is trying to 
reclaim, or nothing else is able to reclaim?  Yeah, that's the big 
problem.  In my opinion, there's three ways of attacking it: (1) 
preallocation so we are less dependent on the page allocator in these 
contexts, (2) memory reserves in extraordinary circumstances to allow 
forward progress (it's already tunable by min_free_kbytes), and (3) 
eventual page allocation failure when neither of these succeed.
--
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/