From mboxrd@z Thu Jan 1 00:00:00 1970 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] Date: Sun, 20 Apr 2014 15:28:30 +0100 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 Return-path: Content-Disposition: inline In-Reply-To: <5351679F.5040908@parallels.com> Sender: owner-linux-mm@kvack.org List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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