Re: [PATCH cgroup/for-3.12] cgroup: make css_for_each_descendant()and friends include the origin css in the iteration

From: Aristeu Rozanski
Date: Mon Aug 05 2013 - 14:57:46 EST


On Sun, Aug 04, 2013 at 07:07:03PM -0400, Tejun Heo wrote:
> I've been wanting to do this for some time and given all the recent
> API updates now seems like a pretty good opportunity. Verified
> freezer and blkcg. The conversions are mostly straight forward but
> I'd much appreciate acks from controller maintainers.
>
> The patch is on top of
>
> cgroup/for-3.12 61584e3f4 ("cgroup: Merge branch 'for-3.11-fixes' into for-3.12")
> + [1] cgroup: use cgroup_subsys_state as the primary subsystem interface handle
> + [2] cgroup: make cgroup_event specific to memcg
>
> and available in the following git branch.
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup.git review-descendant-update
>
> Thanks.
>
> [1] https://lkml.org/lkml/2013/8/1/722
> [2] http://thread.gmane.org/gmane.linux.kernel.cgroups/8726
>
> ------- 8< -------
>
> From 0e84b0865ab8a87f1c1443e4777c20c7f14e13b6 Mon Sep 17 00:00:00 2001
> From: Tejun Heo <tj@xxxxxxxxxx>
> Date: Sun, 4 Aug 2013 19:01:23 -0400
>
> Previously, all css descendant iterators didn't include the origin
> (root of subtree) css in the iteration. The reasons were maintaining
> consistency with css_for_each_child() and that at the time of
> introduction more use cases needed skipping the origin anyway;
> however, given that css_is_descendant() considers self to be a
> descendant, omitting the origin css has become more confusing and
> looking at the accumulated use cases rather clearly indicates that
> including origin would result in simpler code overall.
>
> While this is a change which can easily lead to subtle bugs, cgroup
> API including the iterators has recently gone through major
> restructuring and no out-of-tree changes will be applicable without
> adjustments making this a relatively acceptable opportunity for this
> type of change.
>
> The conversions are mostly straight-forward. If the iteration block
> had explicit origin handling before or after, it's moved inside the
> iteration. If not, if (pos == origin) continue; is added. Some
> conversions add extra reference get/put around origin handling by
> consolidating origin handling and the rest. While the extra ref
> operations aren't strictly necessary, this shouldn't cause any
> noticeable difference.

Looks good. Thanks for the heads up, saved some hours of head scratching
:)

Acked-by: Aristeu Rozanski <aris@xxxxxxxxxx>

--
Aristeu

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