From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) by kanga.kvack.org (Postfix) with ESMTP id AECBD6B0035 for ; Sun, 20 Apr 2014 10:29:16 -0400 (EDT) Received: by mail-wg0-f43.google.com with SMTP id x13so1903492wgg.26 for ; Sun, 20 Apr 2014 07:29:15 -0700 (PDT) Received: from alpha.arachsys.com (alpha.arachsys.com. [2001:9d8:200a:0:9f:9fff:fe90:dbe3]) by mx.google.com with ESMTPS id gw4si1586628wib.114.2014.04.20.07.29.14 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 20 Apr 2014 07:29:15 -0700 (PDT) Date: Sun, 20 Apr 2014 15:28:30 +0100 From: Richard Davies Subject: Protection against container fork bombs [WAS: Re: memcg with kmem limit doesn't recover after disk i/o causes limit to be hit] Message-ID: <20140420142830.GC22077@alpha.arachsys.com> References: <20140416154650.GA3034@alpha.arachsys.com> <20140418155939.GE4523@dhcp22.suse.cz> <5351679F.5040908@parallels.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5351679F.5040908@parallels.com> Sender: owner-linux-mm@kvack.org List-ID: To: Vladimir Davydov , Frederic Weisbecker , David Rientjes , Glauber Costa , Tejun Heo , Max Kellermann , Johannes Weiner , William Dauchy , Tim Hockin , Michal Hocko , Daniel Walsh , Daniel Berrange Cc: cgroups@vger.kernel.org, linux-mm@kvack.org, containers@lists.linux-foundation.org Vladimir Davydov wrote: > Richard Davies wrote: > > I have a simple reproducible test case in which untar in a memcg with a > > kmem limit gets into trouble during heavy disk i/o (on ext3) and never > > properly recovers. This is simplified from real world problems with > > heavy disk i/o inside containers. > > Unfortunately, work on per cgroup kmem limits is not completed yet. > Currently it lacks kmem reclaim on per cgroup memory pressure, which is > vital for using kmem limits in real life. ... > In short, kmem limiting for memory cgroups is currently broken. Do not > use it. We are working on making it usable though. Thanks for explaining the strange errors I got. My motivation is to prevent a fork bomb in a container from affecting other processes outside that container. kmem limits were the preferred mechanism in several previous discussions about two years ago (I'm copying in participants from those previous discussions and give links below). So I tried kmem first but found bugs. What is the best mechanism available today, until kmem limits mature? RLIMIT_NPROC exists but is per-user, not per-container. Perhaps there is an up-to-date task counter patchset or similar? Thank you all, Richard. Some references to previous discussions: Fork bomb limitation in memcg WAS: Re: [PATCH 00/11] kmem controller for memcg: stripped down version http://thread.gmane.org/gmane.linux.kernel/1318266/focus=1319372 Re: [PATCH 00/10] cgroups: Task counter subsystem v8 http://thread.gmane.org/gmane.linux.kernel/1246704/focus=1467310 [RFD] Merge task counter into memcg http://thread.gmane.org/gmane.linux.kernel/1280302 Re: [PATCH -mm] cgroup: Fix task counter common ancestor logic http://thread.gmane.org/gmane.linux.kernel/1212650/focus=1220186 [PATCH] new cgroup controller "fork" http://thread.gmane.org/gmane.linux.kernel/1210878 Re: Process Limit cgroups http://thread.gmane.org/gmane.linux.kernel.cgroups/9368/focus=9369 Re: [lxc-devel] process number limit https://www.mail-archive.com/lxc-devel@lists.sourceforge.net/msg03309.html -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org