Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753554AbbFHTl5 (ORCPT ); Mon, 8 Jun 2015 15:41:57 -0400 Received: from mail-ie0-f170.google.com ([209.85.223.170]:35120 "EHLO mail-ie0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752524AbbFHTlu (ORCPT ); Mon, 8 Jun 2015 15:41:50 -0400 Date: Mon, 8 Jun 2015 12:41:48 -0700 (PDT) From: David Rientjes X-X-Sender: rientjes@chino.kir.corp.google.com To: Austin S Hemmelgarn cc: Michal Hocko , Andrew Morton , linux-mm@kvack.org, LKML Subject: Re: [PATCH] oom: split out forced OOM killer In-Reply-To: <5575E5E6.20908@gmail.com> Message-ID: References: <1433235187-32673-1-git-send-email-mhocko@suse.cz> <557187F9.8020301@gmail.com> <5575E5E6.20908@gmail.com> User-Agent: Alpine 2.10 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1607 Lines: 32 On Mon, 8 Jun 2015, Austin S Hemmelgarn wrote: > I believe so (haven't actually read the patch itself, just the changelog), > although it is only a change for certain configurations to a very specific and > (I hope infrequently) used piece of functionality. Like I said above, if I > wanted to crash my system, I'd be using sysrq-c; and if I'm using sysrq-f, I > want _some_ task to die _now_. > This patch is not a functional change, so I don't interpret your feedback as any support of it being merged. That said, you raise an interesting point of whether sysrq+f should ever trigger a panic due to panic_on_oom. The case can be made that it should ignore panic_on_oom and require the use of another sysrq to panic the machine instead. Sysrq+f could then be used to oom kill a process, regardless of panic_on_oom, and the panic only occurs if userspace did not trigger the kill or the kill itself will fail. I think we should pursue that direction. This patch also changes the text which is output to the kernel log on panic, which we use to parse for machines that have crashed due to no killable memcg processes, so NACK on this patch. There's also no reason to add more source code to try to make things cleaner when it just obfuscates the oom killer code more than it needs to (we don't need to optimize or have multiple entry points). -- 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/