On Mon, Dec 19, 2016 at 05:56:24PM -0800, Andy Lutomirski wrote: > >> Huh? My example in the original email attaches a program in a > >> sub-hierarchy. Are you saying that 4.11 could make that example stop > >> working? > > > > Are you suggesting sub-cgroups should not be allowed to override the filter of a parent cgroup? > > Yes, exactly. I think there are two sensible behaviors: > > a) sub-cgroups cannot have a filter at all of the parent has a filter. > (This is the "punt" approach -- it lets different semantics be > assigned later without breaking userspace.) > > b) sub-cgroups can have a filter if a parent does, too. The semantics > are that the sub-cgroup filter runs first and all side-effects occur. > If that filter says "reject" then ancestor filters are skipped. If > that filter says "accept", then the ancestor filter is run and its > side-effects happen as well. (And so on, all the way up to the root.) So from what I understand the proposed cgroup is not in fact hierarchical at all. @TJ, I thought you were enforcing all new cgroups to be properly hierarchical, that would very much include this one. -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
