Re: [PATCH -mm] cgroup: Fix task counter common ancestor logic

[Frederic Weisbecker <fweisbec-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

On Tue, Nov 08, 2011 at 01:51:11PM -0800, Andrew Morton wrote:
> On Tue,  8 Nov 2011 16:21:10 +0100
> Frederic Weisbecker <fweisbec-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> 
> > To solve this, keep the original cgroup of each thread in the thread
> > group cached in the flex array and pass it to can_attach_task()/attach_task()
> > and cancel_attach_task() so that the correct common ancestor between the old
> > and new cgroup can be safely retrieved for each task.
> 
> OK, thanks.
> 
> We need to work out what to do with this patchset.  ie: should we merge
> it.  I'm not sure that the case has been made?
> 
> Let's please drag this thing onto the table and poke at it for a while.
> Probably everyone has forgotten everything so we'll need to start
> again, sorry.  Perhaps you can (re)start proceedings by telling us why
> it's useful to our users and why we should merge it?

Right, so the main purpose is to have a suitable forkbomb protection
in the lxc containers. It seems that these days, using NR_PROC rlimit is
the prime choice to protect against forkbombs. But we can't use this for
containers because if they run under the same user, they can starve each
others by generating high number of processes. So we need the limit on
number of processes to be per container.

The basic requirement is to be able to run untrustee process inside a
container while protecting against attacks from there without impacting
the rest of the system.

I'm adding in Cc some Lxc people who could perhaps provide more details
and testify we really need this.

> Some mental notes:
> 
> Tim says it would be useful for the things he's doing but doesn't
> appear to have confirmed/tested that.

Yeah, I'm waiting for more details from him. Tim?

> Kay has said that it would not be useful for his plumber's wishlist
> item, which is a shame.

Indeed. I mean it would work but this cgroup subsystem is too much overhead
to be used by an init process (and then all other processes).

> I seem to recall complaining that it doesn't address the forkbomb issue
> for non-cgroups setups, so the forkbomb issue remains unaddressed.

Right. Now if we can find a generic solution to protect against all forkbombs,
something deterministic that can react soon enough so that it doesn't impact
the rest of system, in order to avoid running into some DDOS, then we will
consider it.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe cgroups" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html