[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160520161759.GD5632@htj.duckdns.org>
Date: Fri, 20 May 2016 09:17:59 -0700
From: Tejun Heo <tj@...nel.org>
To: James Bottomley <James.Bottomley@...senPartnership.com>
Cc: Aleksa Sarai <asarai@...e.de>, Li Zefan <lizefan@...wei.com>,
Johannes Weiner <hannes@...xchg.org>,
Aleksa Sarai <cyphar@...har.com>, cgroups@...r.kernel.org,
linux-kernel@...r.kernel.org, dev@...ncontainers.org
Subject: Re: [PATCH v4 0/2] cgroup: allow management of subtrees by new
cgroup namespaces
Hello, James.
On Fri, May 20, 2016 at 12:09:10PM -0400, James Bottomley wrote:
> I think it's just different definitions. If you take on our definition
> of being able to set up a container without any admin intervention, do
> you see our problem: we can't get the initial delegation of the
> hierarchy.
Yeah, I can see the difference but we can't solve that by special
casing NS case. This is stemming from the fact that an unpriv
application can't create its sub-cgroups without explicit delegation
from the root and that has always been an explicit design choice.
It's tied to who's responsible for cleanup afterwards and what happens
when the process gets migrated to a different cgroup. The latter is
an important issue on v1 hierarchies because migrating tasks sometimes
is used as a way to control resource distribution.
Thanks.
--
tejun
Powered by blists - more mailing lists