linux-kernel - Re: [RFD] cgroup: about multiple hierarchies

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:	Sat, 3 Mar 2012 08:26:04 -0600
From:	Serge Hallyn <serge.hallyn@...onical.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	Tejun Heo <tj@...nel.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	containers@...ts.linux-foundation.org,
	Kay Sievers <kay.sievers@...y.org>,
	linux-kernel@...r.kernel.org,
	Christoph Hellwig <hch@...radead.org>,
	Lennart Poettering <lennart@...ttering.net>,
	cgroups@...r.kernel.org, Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [RFD] cgroup: about multiple hierarchies

Quoting Eric W. Biederman (ebiederm@...ssion.com):
> 4.  Only allow a single controller per hierarchy.  So that we can
> make reasonable choice points.  If the hierarchy is to be about
> policy I am baffled by concept of putting multiple controllers in
> a single hierarchy.  Because where you clump things together for
> policy for one controller in general does not seem to be where you
> want to clump things together for another controller.

This I agree with.  The only reasonably use I've seen for the
composed hierarchies is the ns cgroup, which was the wrong tool
for what it wanted to do anyway.  With ns cgroup deprecated, every
modern setup I've seen mounts each cgroup separately.

> > So, I mean, I don't know.  What do other people think?  Is this a
> > unnecessary worry?  Are people generally happy with the way things
> > are?  Lennart, Kay, what do you guys think?
> 
> I think the current situation is crazy.
> 
> I especially think it is crazy that inside a container I can't create
> a fresh set of cgroup mounts, and establish a fresh "hierarchy" relative
> to the process that created the cgroup mounts.  It sucks that
> controllers may nest fine but hierarchies don't nest.

Again I agree here.  In the past there has been brought up the idea
of fake cgroup roots ( http://thread.gmane.org/gmane.linux.kernel/1197643 )
I haven't looked in detail, but I know some people hated this particular
idea.  But it tried to solve this problem.

Perhaps we can attack this in two stages.

1. get rid of the ability to compose cgroups.  See how much this
simplifies the code.

2. add the ability to somehow namespace the cgroup mounts to allow a
container to freshly mount cgroups.

-serge
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/