linux-kernel - Re: Understanding cgroups

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>] [<thread-prev] [day] [month] [year] [list]

Date:	Thu, 28 Oct 2010 15:22:20 -0700
From:	Paul Menage <menage@...gle.com>
To:	Tommaso Cucinotta <tommaso.cucinotta@...up.it>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Dhaval Giani <dhaval.giani@...il.com>,
	Linux Containers <containers@...ts.linux-foundation.org>
Subject: Re: Understanding cgroups

On Thu, Oct 28, 2010 at 8:44 AM, Tommaso Cucinotta
<tommaso.cucinotta@...up.it> wrote:
> a) why doesn't a cgroup object directly point to a css_set one, but to a
> list of them (via cg_cgroup_list elements) ?

Each task is in one cgroup per mounted hierarchy. There's no
requirement that different hierarchies have isomorphic partitions of
tasks (in fact that would somewhat defeat the point of mounting
separate hierarchies). So even though all the tasks in a cgroup share
css pointers for the subsystems attached to that cgroup's hierarchy,
in general they will have different total sets of css pointers. Hence
the multiple css_set objects associated with a cgroup.

>    it seems that a cgroup object may be associated to multiple css_set
> objects, which in turn contain vectors of
>    cgroup_subsys_state;
> b) however, cgroup.subsys[] would point to a single cgroup_subsys_state
> object per subsys_id,

No, it points to a single cgroup_subsys_state for each subsys that's
bound to the cgroup's hierarchy, and NULL for all others.

> so, what is the
>    difference between cgroup.subsys[] and css_set.subsys[] ? (or, are these
> all redundant pointers and point
>    to the same cgroup_subsys_state objects ?)

css_set.subsys is the union of all the (disjoint) sets of subsys
pointers in the cgroups that a task is a member of (one cgroup per
hierarchy).

Yes, the pointers in the css_set are redundant in that they could be
determined by following more pointers, but for efficiency they're all
available directly in the css_set. (Also this typically allows a
single refcount inc/dec in the task fork/exit case)

> c) is css_set.cg_links used to point to (the head of) a list of
> cg_cgroup_link objects,

Yes. It's the head of a list of cg_cgroup_link objects, each of which
has a pointer to this css_set and a pointer to a cgroup of which this
css_set represents membership. (One per hierarchy)

> or is it used to link multiple css_set objects into
> a list ?

In a way this is also true, but only indirectly - the cg_cgroup_link
objects form a two-dimensional doubly-linked list lattice that
represents the many:many relationship between cgroup and css_set. One
dimension's linked lists are headed by css_set objects, the other
dimension is headed by cgroups.

Paul
--
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/