Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754329AbbFELNJ (ORCPT ); Fri, 5 Jun 2015 07:13:09 -0400 Received: from cantor2.suse.de ([195.135.220.15]:44693 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751240AbbFELNF (ORCPT ); Fri, 5 Jun 2015 07:13:05 -0400 Date: Fri, 5 Jun 2015 13:13:02 +0200 From: Michal Hocko To: David Rientjes Cc: Andrew Morton , Tetsuo Handa , linux-mm@kvack.org, LKML Subject: Re: [PATCH] oom: always panic on OOM when panic_on_oom is configured Message-ID: <20150605111302.GB26113@dhcp22.suse.cz> References: <1433159948-9912-1-git-send-email-mhocko@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2798 Lines: 57 On Thu 04-06-15 16:12:27, David Rientjes wrote: > On Mon, 1 Jun 2015, Michal Hocko wrote: > > > panic_on_oom allows administrator to set OOM policy to panic the system > > when it is out of memory to reduce failover time e.g. when resolving > > the OOM condition would take much more time than rebooting the system. > > > > out_of_memory tries to be clever and prevent from premature panics > > by checking the current task and prevent from panic when the task > > has fatal signal pending and so it should die shortly and release some > > memory. This is fair enough but Tetsuo Handa has noted that this might > > lead to a silent deadlock when current cannot exit because of > > dependencies invisible to the OOM killer. > > > > panic_on_oom is disabled by default and if somebody enables it then any > > risk of potential deadlock is certainly unwelcome. The risk is really > > low because there are usually more sources of allocation requests and > > one of them would eventually trigger the panic but it is better to > > reduce the risk as much as possible. > > > > Let's move check_panic_on_oom up before the current task is > > checked so that the knob value is . Do the same for the memcg in > > mem_cgroup_out_of_memory. > > > > Reported-by: Tetsuo Handa > > Signed-off-by: Michal Hocko > > Nack, this is not the appropriate response to exit path livelocks. By > doing this, you are going to start unnecessarily panicking machines that > have panic_on_oom set when it would not have triggered before. If there > is no reclaimable memory and a process that has already been signaled to > die to is in the process of exiting has to allocate memory, it is > perfectly acceptable to give them access to memory reserves so they can > allocate and exit. Under normal circumstances, that allows the process to > naturally exit. With your patch, it will cause the machine to panic. Isn't that what the administrator of the system wants? The system is _clearly_ out of memory at this point. A coincidental exiting task doesn't change a lot in that regard. Moreover it increases a risk of unnecessarily unresponsive system which is what panic_on_oom tries to prevent from. So from my POV this is a clear violation of the user policy. > It's this simple: panic_on_oom is not a solution to workaround oom killer > livelocks and shouldn't be suggested as the canonical way that such > possibilities should be addressed. I wasn't suggesting that at all. -- Michal Hocko SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/