>> >> However, it should be noted that organisational operations (adding and >> >> removing tasks from a PIDs hierarchy) will *not* be prevented. >> > >> > This is how you spell: broken controller. >> >> This has been discussed before. Organisational operations (i.e. >> attaching to a cgroup) are not to be blocked by a cgroup controller in >> the unified hierarchy. You simply can't escape out of a parent >> cgroup's limit through attaching to a child cgroup (because you will >> attach either before the fork checks against the cgroup [in which case >> the child's limit is followed -- which means you also follow the >> parent's limit] or after it checks [which means you'll hit the >> parent's limit and won't be able to fork]). > > That's complete and utter nonsense. What has the parent limit to do > with the overflow of the child limit? > > parent: limit 100 usecnt 80 > child: limit 10 usecnt 10 > > So moving anything into child is violating the constraints and has to > be refused. Anything else is just dirty hackery. Whoops. Yes, you're completely right. All right, I'll fix up the patchset in a few days. -- Aleksa Sarai (cyphar) www.cyphar.com -- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
