Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932792Ab0BDVtK (ORCPT ); Thu, 4 Feb 2010 16:49:10 -0500 Received: from smtp-out.google.com ([216.239.33.17]:40738 "EHLO smtp-out.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757684Ab0BDVtH (ORCPT ); Thu, 4 Feb 2010 16:49:07 -0500 DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id: references:user-agent:mime-version:content-type:x-system-of-record; b=YEC0CcPDtrtf8tEEBjf5myChooI0T9opKaVzdnZOZj+p4yonzPLgCp8zFTmQLfPyz W3fIYJl9G58rty90wRGqg== Date: Thu, 4 Feb 2010 13:48:59 -0800 (PST) From: David Rientjes X-X-Sender: rientjes@chino.kir.corp.google.com To: Rik van Riel cc: Lubos Lunak , Balbir Singh , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton , KOSAKI Motohiro , Nick Piggin , Jiri Kosina Subject: Re: Improving OOM killer In-Reply-To: <4B6A1241.60009@redhat.com> Message-ID: References: <201002012302.37380.l.lunak@suse.cz> <20100203170127.GH19641@balbir.in.ibm.com> <201002032355.01260.l.lunak@suse.cz> <4B6A1241.60009@redhat.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-System-Of-Record: true Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1803 Lines: 44 On Wed, 3 Feb 2010, Rik van Riel wrote: > > Do you have any comments about the forkbomb detector or its threshold that > > I've put in my heuristic? I think detecting these scenarios is still an > > important issue that we need to address instead of simply removing it from > > consideration entirely. > > I believe that malicious users are best addressed in person, > or preemptively through cgroups and rlimits. > Forkbombs need not be the result of malicious users. > Having a process with over 500 children is quite possible > with things like apache, Oracle, postgres and other forking > daemons. > It's clear that the forkbomb threshold would need to be definable from userspace and probably default to something high such as 1000. Keep in mind that we're in the oom killer here, though. So we're out of memory and we need to kill something; should Apache, Oracle, and postgres not be penalized for their cost of running by factoring in something like this? (lowest rss size of children) * (# of first-generation children) / (forkbomb threshold) > Killing the parent process can result in the service > becoming unavailable, and in some cases even data > corruption. > There's only one possible rememdy for that, which is OOM_DISABLE; the oom killer cannot possibly predict data corruption as the result of killing a process and this is no different. Everything besides init, kthreads, OOM_DISABLE threads, and threads that do not share the same cpuset, memcg, or set of allowed mempolicy nodes are candidates for oom kill. -- 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/