From mboxrd@z Thu Jan 1 00:00:00 1970 From: Frederic Weisbecker Subject: Re: [PATCH -mm] cgroup: Fix task counter common ancestor logic Date: Thu, 24 Nov 2011 14:24:51 +0100 Message-ID: <20111124132442.GA18579@somewhere.redhat.com> References: <1320765670-14181-1-git-send-email-fweisbec@gmail.com> <20111108135111.6a74f1d2.akpm@linux-foundation.org> Mime-Version: 1.0 Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=gqBW3+MJh+ZYmhiE0eGNcTpXw+Qe+5J/LAzPwL6XRac=; b=iaIaPjBEKuslvuDhZKpcZ00Lu/BUM2AG2q9josOvPCnv82HYlL2kKM2bCmSniGXTW2 o1mI+IDGuxJ561cH/bSQVraMLVo6qYAFDjlbvYMtfmEp4JhF1S46YmIzwHEZON8Xfb/e KAr4f8HEy4yUL7fr50ma+UQgpaoS8K15OaIXk= Content-Disposition: inline In-Reply-To: <20111108135111.6a74f1d2.akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> Sender: cgroups-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Andrew Morton , Daniel J Walsh , "Daniel P. Berrange" , Tim Hockin Cc: LKML , Ben Blum , Li Zefan , Paul Menage , Tejun Heo , Containers , Cgroups , KAMEZAWA Hiroyuki On Tue, Nov 08, 2011 at 01:51:11PM -0800, Andrew Morton wrote: > On Tue, 8 Nov 2011 16:21:10 +0100 > Frederic Weisbecker 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756069Ab1KXNZF (ORCPT ); Thu, 24 Nov 2011 08:25:05 -0500 Received: from mail-vx0-f174.google.com ([209.85.220.174]:62610 "EHLO mail-vx0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754055Ab1KXNZC (ORCPT ); Thu, 24 Nov 2011 08:25:02 -0500 Date: Thu, 24 Nov 2011 14:24:51 +0100 From: Frederic Weisbecker To: Andrew Morton , Daniel J Walsh , "Daniel P. Berrange" , Tim Hockin Cc: LKML , Ben Blum , Li Zefan , Paul Menage , Tejun Heo , Containers , Cgroups , KAMEZAWA Hiroyuki Subject: Re: [PATCH -mm] cgroup: Fix task counter common ancestor logic Message-ID: <20111124132442.GA18579@somewhere.redhat.com> References: <1320765670-14181-1-git-send-email-fweisbec@gmail.com> <20111108135111.6a74f1d2.akpm@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111108135111.6a74f1d2.akpm@linux-foundation.org> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.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 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.