Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755998AbbESNMH (ORCPT ); Tue, 19 May 2015 09:12:07 -0400 Received: from www.linutronix.de ([62.245.132.108]:54876 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753409AbbESNMF (ORCPT ); Tue, 19 May 2015 09:12:05 -0400 Date: Tue, 19 May 2015 15:11:34 +0200 (CEST) From: Thomas Gleixner To: Aleksa Sarai cc: Peter Zijlstra , Tejun Heo , lizefan@huawei.com, mingo@redhat.com, richard@nod.at, =?ISO-8859-15?Q?Fr=E9d=E9ric_Weisbecker?= , linux-kernel@vger.kernel.org, cgroups@vger.kernel.org Subject: Re: [PATCH v12 8/8] cgroup: implement the PIDs subsystem In-Reply-To: Message-ID: References: <1431960667-26593-1-git-send-email-cyphar@cyphar.com> <1431960667-26593-9-git-send-email-cyphar@cyphar.com> <20150519080055.GA3644@twins.programming.kicks-ass.net> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1319 Lines: 37 On Tue, 19 May 2015, Aleksa Sarai wrote: > >> However, it should be noted that organisational operations (adding and > >> removing tasks from a PIDs hierarchy) will *not* be prevented. > > > > This is how you spell: broken controller. > > This has been discussed before. Organisational operations (i.e. > attaching to a cgroup) are not to be blocked by a cgroup controller in > the unified hierarchy. You simply can't escape out of a parent > cgroup's limit through attaching to a child cgroup (because you will > attach either before the fork checks against the cgroup [in which case > the child's limit is followed -- which means you also follow the > parent's limit] or after it checks [which means you'll hit the > parent's limit and won't be able to fork]). That's complete and utter nonsense. What has the parent limit to do with the overflow of the child limit? parent: limit 100 usecnt 80 child: limit 10 usecnt 10 So moving anything into child is violating the constraints and has to be refused. Anything else is just dirty hackery. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/