From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yh0-f47.google.com (mail-yh0-f47.google.com [209.85.213.47]) by kanga.kvack.org (Postfix) with ESMTP id 0E2196B0035 for ; Sun, 20 Apr 2014 14:35:42 -0400 (EDT) Received: by mail-yh0-f47.google.com with SMTP id 29so2902676yhl.6 for ; Sun, 20 Apr 2014 11:35:41 -0700 (PDT) Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [2607:f8b0:4002:c07::230]) by mx.google.com with ESMTPS id v6si27161939yhm.170.2014.04.20.11.35.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 20 Apr 2014 11:35:40 -0700 (PDT) Received: by mail-yk0-f176.google.com with SMTP id 19so2778933ykq.21 for ; Sun, 20 Apr 2014 11:35:40 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20140420142830.GC22077@alpha.arachsys.com> References: <20140416154650.GA3034@alpha.arachsys.com> <20140418155939.GE4523@dhcp22.suse.cz> <5351679F.5040908@parallels.com> <20140420142830.GC22077@alpha.arachsys.com> Date: Sun, 20 Apr 2014 11:35:40 -0700 Message-ID: Subject: Re: Protection against container fork bombs [WAS: Re: memcg with kmem limit doesn't recover after disk i/o causes limit to be hit] From: Tim Hockin Content-Type: multipart/alternative; boundary=001a1133d9665103a304f77da68d Sender: owner-linux-mm@kvack.org List-ID: To: Richard Davies Cc: Michal Hocko , Vladimir Davydov , Frederic Weisbecker , Johannes Weiner , containers@lists.linux-foundation.org, Glauber Costa , Tejun Heo , David Rientjes , linux-mm@kvack.org, Daniel Walsh , William Dauchy , Max Kellermann , cgroups@vger.kernel.org, Daniel Berrange --001a1133d9665103a304f77da68d Content-Type: text/plain; charset=UTF-8 I would still be in strong support of a cgroup replacement for NPROC rlimit. On Apr 20, 2014 7:29 AM, "Richard Davies" wrote: > 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 > --001a1133d9665103a304f77da68d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I would still be in strong support of a cgroup replacement f= or NPROC rlimit.

On Apr 20, 2014 7:29 AM, "Richard Davies&qu= ot; <richard@arachsys.com>= ; wrote:
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 wi= th
> > 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 i= s
> 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 me= mcg: stripped down version
http://thread.gmane.org/gmane.linux.kernel/1318266/fo= cus=3D1319372

Re: [PATCH 00/10] cgroups: Task counter subsystem v8
http://thread.gmane.org/gmane.linux.kernel/1246704/fo= cus=3D1467310

[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/fo= cus=3D1220186

[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=3D9369

Re: [lxc-devel] process number limit
https://www.mail-archive.com/lxc-devel@lists.= sourceforge.net/msg03309.html
--001a1133d9665103a304f77da68d-- -- 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