[LTP] [PATCH v1] tst_cgroup.c: Force tst_cg_scan only scan specific cgroup version if needs_ver exist

Wei Gao wegao@suse.com
Mon Dec 9 12:25:20 CET 2024


On Thu, Dec 05, 2024 at 02:16:38PM +0100, Cyril Hrubis wrote:
> Hi!
> > > You are supposed to get an error here, at least that is what I thought.
> > 
> > That depends -- if the controller's tasks are all in its (only) root
> > cgroup, it can be re-bind between hierarchies (v1 to v2 or vice versa).
> > 
> > > I do get error here on vanilla 6.10 but on debian 6.1 the mount succeeds
> > > as well. CCing Michal.
> > 
> > If /sys/fs/cgroup/cgroup.subtree_control contains `cpuset`, it's likely
> > used by some of the services, hence not all tasks are in the root cgroup
> > and re-binding fails. That's what can differ between systems.
> > 
> > > Michal I was under an impression that a controller that has been bound
> > > to v2 cannot be removed from there and bound to v1 anymore, but it seems
> > > that it may happen in some cases.
> > 
> > It can happen under the condition above.
> > (And in a future kernel it may be truly unavailable in v1 with
> > !CONFIG_CPUSETS_V1.)
> 
> Thanks for the clarifications.
> 
> I still do not think that re-binding controllers to v1 is a good idea
> though. Firstly v1 is being phased out and we will eventually get rid
> of it, so there is no point in investing too much effort into v1 testing
> in hybrid environments.
> 
> And secondly I fear that we may end up skipping v2 tests because of the
> rebinding. What I think may happen is that the cgroup cleanup is
> asynchronous which means that there still would be remnants of the v1
> cpuset cgroup even after the particular v1 test would exit, which would
> cause next test a v2 test to be skipped, because the rebinding would
> fail.

Thanks all for feedback, so we can skip this patch.

> 
> -- 
> Cyril Hrubis
> chrubis@suse.cz


More information about the ltp mailing list