linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Richard Davies <richard@arachsys.com>
To: Vladimir Davydov <vdavydov@parallels.com>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	David Rientjes <rientjes@google.com>,
	Glauber Costa <glommer@parallels.com>, Tejun Heo <tj@kernel.org>,
	Max Kellermann <mk@cm4all.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	William Dauchy <wdauchy@gmail.com>,
	Tim Hockin <thockin@hockin.org>, Michal Hocko <mhocko@suse.cz>,
	Daniel Walsh <dwalsh@redhat.com>,
	Daniel Berrange <berrange@redhat.com>
Cc: cgroups@vger.kernel.org, linux-mm@kvack.org,
	containers@lists.linux-foundation.org
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	[thread overview]
Message-ID: <20140420142830.GC22077@alpha.arachsys.com> (raw)
In-Reply-To: <5351679F.5040908@parallels.com>

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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  parent reply	other threads:[~2014-04-20 14:29 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-16 15:46 memcg with kmem limit doesn't recover after disk i/o causes limit to be hit Richard Davies
2014-04-18 15:59 ` Michal Hocko
2014-04-18 17:57   ` Vladimir Davydov
2014-04-18 18:20     ` Michal Hocko
2014-04-18 18:37       ` Vladimir Davydov
2014-04-20 14:28     ` Richard Davies [this message]
2014-04-20 18:35       ` Protection against container fork bombs [WAS: Re: memcg with kmem limit doesn't recover after disk i/o causes limit to be hit] Tim Hockin
2014-04-22 18:39       ` Dwight Engen
2014-04-22 20:05         ` Richard Davies
2014-04-22 20:13           ` Tim Hockin
2014-04-23  6:07           ` Marian Marinov
2014-04-23 12:49             ` Dwight Engen
2014-04-28 18:00               ` Serge Hallyn
2014-04-29  7:25                 ` Michal Hocko
2014-04-29 13:03                   ` Serge Hallyn
2014-04-29 13:57                     ` Marian Marinov
2014-04-29 14:04                     ` Tim Hockin
2014-04-29 15:43                     ` Michal Hocko
2014-04-29 16:06                       ` Tim Hockin
2014-04-29 16:51                         ` Frederic Weisbecker
2014-04-29 16:59                           ` Tim Hockin
2014-04-29 17:06                             ` Michal Hocko
2014-04-29 17:30                               ` Dwight Engen
2014-04-29 18:09                                 ` Richard Davies
2014-04-29 18:27                                   ` Michal Hocko
2014-04-29 18:39                                     ` Richard Davies
2014-04-29 19:03                                       ` Michal Hocko
2014-04-29 21:36                                     ` Marian Marinov
2014-04-30 13:31                                       ` Michal Hocko
2014-04-29 21:44                             ` Frederic Weisbecker
2014-04-30 13:12                               ` Daniel J Walsh
2014-04-30 13:28                                 ` Frederic Weisbecker
2014-05-06 11:40               ` Marian Marinov
2014-05-07 17:15                 ` Dwight Engen
2014-05-07 22:39                   ` Marian Marinov
2014-05-08 15:25                     ` Richard Davies
2014-06-10 14:50               ` Marian Marinov
2014-06-10 12:18           ` Alin Dobre

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140420142830.GC22077@alpha.arachsys.com \
    --to=richard@arachsys.com \
    --cc=berrange@redhat.com \
    --cc=cgroups@vger.kernel.org \
    --cc=containers@lists.linux-foundation.org \
    --cc=dwalsh@redhat.com \
    --cc=fweisbec@gmail.com \
    --cc=glommer@parallels.com \
    --cc=hannes@cmpxchg.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.cz \
    --cc=mk@cm4all.com \
    --cc=rientjes@google.com \
    --cc=thockin@hockin.org \
    --cc=tj@kernel.org \
    --cc=vdavydov@parallels.com \
    --cc=wdauchy@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).