On Thu, Oct 04, 2018 at 09:40:57PM +0200, Michael Kerrisk (man-pages) wrote: > Hello Tejun, > > Suppose we have the following scenario: > > x [d] (pids) > y [dt] (pids) > p [t] > q [t] > r [t] > z [d] > > Here, x/y is a "domain threaded root" with a threaded controller > (the 'pids' controller) enabled. (In this scenario, there are no > member processes in any of the cgroups.) > > Suppose we now convert x/z to "threaded" type: > > # echo threaded > x/z/cgroup.type > > Now we end up in the following state: > > x [dt] (pids) > y [inv] (pids) > p [t] > q [t] > r [t] > z [t] > > This seems odd. x/y is now of "domain invalid" type with a controller > enabled! This feels like a violation of the rules, since we can't > in other circumstances do anything with a "domain invalid" cgroup > except convert it to "threaded". In particular, we can't create > child cgroups under a "domain invalid" cgroup, or add member processes > to the cgroup, or *enable controllers in the cgroup*. In fact, when > doing the > > # echo threaded > x/z/cgroup.type > > I had expected a write(2) error because the state of x/y should > (I thought) not be permitted. > > Your thoughts? Just a note: there are now some cgroup core kernel selftests in tools/testing/selftests/cgroup/test_core.c . It's fairly easy to add new tests to cover tricky cases like this one. It always nice to have more tests, and also easier to show and reproduce a problem. Thanks!
