From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756107AbbESNnj (ORCPT ); Tue, 19 May 2015 09:43:39 -0400 Received: from mail-ig0-f175.google.com ([209.85.213.175]:38463 "EHLO mail-ig0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755853AbbESNnW (ORCPT ); Tue, 19 May 2015 09:43:22 -0400 MIME-Version: 1.0 X-Originating-IP: [122.106.150.15] In-Reply-To: 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> Date: Tue, 19 May 2015 23:43:21 +1000 Message-ID: Subject: Re: [PATCH v12 8/8] cgroup: implement the PIDs subsystem From: Aleksa Sarai To: Thomas Gleixner Cc: Peter Zijlstra , Tejun Heo , lizefan@huawei.com, mingo@redhat.com, richard@nod.at, =?UTF-8?B?RnLDqWTDqXJpYyBXZWlzYmVja2Vy?= , linux-kernel@vger.kernel.org, cgroups@vger.kernel.org Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org >> >> 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. Whoops. Yes, you're completely right. All right, I'll fix up the patchset in a few days. -- Aleksa Sarai (cyphar) www.cyphar.com