[LTP] [RFC PATCH] tst_cgroup: Avoid mixing mounts V1 and V2 simultaneously

[Li Wang]

Hi Cyril,

On Fri, Apr 28, 2023 at 9:30 PM Li Wang <liwang@redhat.com> wrote:

>
>
> On Fri, Apr 28, 2023 at 9:12 PM Cyril Hrubis <chrubis@suse.cz> wrote:
>
>> Hi!
>> > That's the original design. We tried to keep flexible but ignored
>> > one exception V1 mounts all controllers and V2 only basic mount.
>> > (No controllers conflict in this mounting).
>> >
>> > From my observation, if a system(e.g. RHEL8) only announces
>> > Cgroup V1 support but does not guarantee V2 to be used.
>> > A test required 'CTRL_BASE' could mount V2 success but
>> > that V2 is only part work and test will get TBROK.
>> > We are unable to say this situation is a bug.
>>
>> So the V2 does not actually work unless there is at least one controller
>> enabled? That sounds like a bug to me, my system actually uses v1
>> controllers and unified hierarchy at the same time. The unified
>> hierarchy is used to group deamon processes and kill them with the
>> cgropu.kill if needed.
>
>
> Hmm, let me investigate...
>

After talking with our Cgroup colleagues. I've been told that on my RHEL8,
the 'cgroup.kill' is too new to have.

The default Cgroup is V1 and if we want V2 singly,  it could be explicitly
enabled
via "systemd.unified_cgroup_hierarchy=1" kernel parameters. But so far V2
is not supporting such a new feature. That's why I couldn't find
'cgroup.kill'
after mounting V2 on RHEL8.

And the mainline kernel merges this feature since v5.14.
$ git describe --contains 661ee6280931548f
v5.14-rc1~108^2~8

So, the problem is not caused by mixing V1 and V2. I misunderstood it
before.

Please ignore my patch, the problem can be resolved by:

+       if (!SAFE_CG_HAS(cg_child_test_simple, "cgroup.kill")) {
+               cg_child_test_simple =
tst_cg_group_rm(cg_child_test_simple);
+               tst_brk(TCONF, "cgroup.kill is not supported on your
distribution");
+       }
+

to skip the test gracefully if there is no 'cgroup.kill' interface.
(thus GAO Wei needs to rebase his patch again)

-- 
Regards,
Li Wang