<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 23, 2020 at 7:03 PM Richard Palethorpe <<a href="mailto:rpalethorpe@suse.de">rpalethorpe@suse.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello,<br>
<br>
Li Wang <<a href="mailto:liwang@redhat.com" target="_blank">liwang@redhat.com</a>> writes:<br>
<br>
> Many of our LTP tests need Control Group in the configuration,<br>
> this patch makes cgroup unified mounting at setup phase to be<br>
> possible. The method is extracted from mem.h with the purpose<br>
> of extendible for further developing, and trying to compatible<br>
> the current two versions of cgroup,<br>
><br>
> It's hard to make all APIs be strictly consistent because there<br>
> are many differences between v1 and v2. But it capsulate the detail<br>
> of cgroup mounting in high-level functions, which will be easier<br>
> to use cgroup without considering too much technical thing.   <br>
><br>
> Btw, test get passed on RHEL7(x86_64), RHEL8(ppc64le),<br>
> Fedora32(x86_64).<br>
<br>
This appears to be broken on SUSE.<br>
<br>
> +enum tst_cgroup_ver tst_cgroup_version(void)<br>
> +{<br>
> +     if (tst_cgroup_check("cgroup2")) {<br>
> +             if (!tst_is_mounted("cgroup2") && tst_is_mounted("cgroup"))<br>
<br>
Unfortunately this is backwards: if a cgroup controller is mounted<br>
(e.g. memory) in the v1 separated hierarchy then it is not available in<br>
the cgroup v2 unified hierarchy even though the v2 unified hierarchy<br>
exists.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">That's on purpose because we don't want the user to mix v1 and v2 in using.</div><div class="gmail_default" style="font-size:small">In other words, if a version of cgroup has been chosen on a SUT then LTP </div><div class="gmail_default" style="font-size:small">follows in the same version.</div><br></div><div><div class="gmail_default" style="font-size:small">The cgroup lib choose cgroup version likes:</div></div><div><div class="gmail_default" style="font-size:small">      * system doesn't support any cgroup(v1, v2): TCONF</div>      * system only support cgroup v1: choose v1<br>      * system only support cgroup v2: choose v2<br>      * system support v1 & v2 but mounting v1: chosse v1<span class="gmail_default" style="font-size:small">   <=== this is what you met</span><br>      * system support v1 & v2 but mounting v2: choose v2<br>      * system support v1 & v2 but mounting none: choose v2<br><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
So ksm{03,04} fails with:<br>
<br>
safe_file_ops.c:299: BROK: Failed to close FILE<br>
'/tmp/cgroup_mem/cgroup.subtree_control' at tst_cgroup.c:301: ENOENT (2)<br>
<br>
because we have the memory controller (in fact all the controllers)<br>
mounted in the V1 way, but we also have the cgroup2 mounted. If I<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">Hmm, this is a situation that system mount v1&v2 at the same time.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">So the ksm03/4 choose v2 automatically but hit a problem in cgroup_v2 using.</div><div class="gmail_default" style="font-size:small">I pesonally think it mainly imputes to the SUT config in cgroup, because that<br></div><div class="gmail_default" style="font-size:small">makes cgroup_v2 has no actuall controllers in the <span class="gmail_default"></span>cgroup.controllers. After</div><div class="gmail_default" style="font-size:small">umounting all V1 hierarchies, the controllers get back into V2.</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
unmount the memory controller from V1 then the test passes.<br>
<br>
Another potential problem is that it may be possible to remove access to<br>
controllers some other way in which case you have to check<br>
<span class="gmail_default" style="font-size:small"></span>cgroup.controllers to see what is available. OTOH maybe this is not<br>
possible because you mount a new cgroup2 hierarchy?<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">I'm not sure about this.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">To be honest, I hope a Linux distribution provides a pure way in cgroup</div><div class="gmail_default" style="font-size:small">using, which means just mounting V1 or V2 but not to mix together. Or, do</div></div><div class="gmail_default" style="font-size:small">you think LTP should handle the situation for the v1&v2 mixing mount?</div></div><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>Regards,<br></div><div>Li Wang<br></div></div></div></div>