From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753133AbbFAPMt (ORCPT ); Mon, 1 Jun 2015 11:12:49 -0400 Received: from prod-mail-xrelay02.akamai.com ([72.246.2.14]:34437 "EHLO prod-mail-xrelay02.akamai.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751566AbbFAPMk (ORCPT ); Mon, 1 Jun 2015 11:12:40 -0400 Date: Mon, 1 Jun 2015 11:12:39 -0400 From: Eric B Munson To: Michal Hocko Cc: Andrew Morton , David Rientjes , Tetsuo Handa , linux-mm@kvack.org, LKML Subject: Re: [PATCH] oom: always panic on OOM when panic_on_oom is configured Message-ID: <20150601151239.GA14282@akamai.com> References: <1433159948-9912-1-git-send-email-mhocko@suse.cz> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="r5Pyd7+fXNt84Ff3" Content-Disposition: inline In-Reply-To: <1433159948-9912-1-git-send-email-mhocko@suse.cz> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --r5Pyd7+fXNt84Ff3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, 01 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > Reported-by: Tetsuo Handa > Signed-off-by: Michal Hocko I was initially going to complain about this causing the machine to panic when a cgroup is oom, but the machine is not. However after reading check_panic_on_oom(), that behavior is controllable. Reviewed-by: Eric B Munson --r5Pyd7+fXNt84Ff3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJVbHZnAAoJELbVsDOpoOa9zd4P/jiiBTF4ehhpmMsnmi4FRUtY MxSQn12YLu5gXdUJ5Yg0f/qrqbqvJSP7MZ9gWt1Bnt3tVvyXSSUvUzauDnKbiSIm /nzr7/eQ0xYxCj3QCQCqKqnMMnWnsnwmwHspSKtIi3qdEOELMuDreWBinihgzxmF Yo/K0Tw32xicSdVrvnev2MwvrebDhrpuAxBfwe+IZf4mcF+ZAfE3kWOO3lNjkBTR RNKbo5XR8Dgs477ZSYISgJFXh7zHzbuLRGtUmibTKG7KQQOqsg1ec8ogZ/6CM5V0 lsRkh5SszXg0saN2Q7oibEf0BpZk1OBAidVFwVOpMrAvESXCnmmW5qg+wkv3btM4 /+0Ok3nYrVnfcNSxli4IxMrr/WgpGX6k2jNr+sanwx3BAUxiOx2O8PvgqQHPqa36 PJIZnH5WLfkkeYaCtGPypkQLb5VUtK3N3V7C+BHr/su4U0HlEUCxFOoyCEGXHgE1 VVcfWZp4MAW56bhgtut7O+H7Th3WAMbxSGAlYKeR6EXTdKL4WcQAkMUPtZseB7VE W9Zm8lilmv/HXPlHNXlqXnYqIf1yZbX7ik+Dum8Aa94oGxO0coMkh2ImvEusqqxr xUB3j6qpBfydYjbpSSpTyob9TOSk9jdc39Eo71Cahz64jd26WXM39avQx9mmFIyb wM+guHi6EJ22EvdIcb/1 =3ixX -----END PGP SIGNATURE----- --r5Pyd7+fXNt84Ff3--