linux-kernel - Re: Writing "+pids" to cgroup.subtree

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 5 Dec 2017 17:44:10 +0100
From:   "Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>
To:     Tejun Heo <tj@...nel.org>
Cc:     lkml <linux-kernel@...r.kernel.org>,
        Lennart Poettering <lennart@...ttering.net>
Subject: Re: Writing "+pids" to cgroup.subtree_control flie yields EINVAL

Hello Tejun,

On 5 December 2017 at 17:00, Tejun Heo <tj@...nel.org> wrote:
> Hello, Michael.
>
> On Tue, Dec 05, 2017 at 08:45:19AM +0100, Michael Kerrisk (man-pages) wrote:
>> b) The reason for my initial problems was this test in
>> the kernel in cpu_cgroup_can_attach():
>>
>> #ifdef CONFIG_RT_GROUP_SCHED
>>                 if (!sched_rt_can_attach(css_tg(css), task))
>>                         return -EINVAL;
>> #else
>>                 /* We don't support RT-tasks being in separate groups */
>>                 if (task->sched_class != &fair_sched_class)
>>                         return -EINVAL;
>> #endif
>>
>> I don't have CONFIG_RT_GROUP_SCHED, and the second 'if' was yielding
>> false because of some SCHED_RR processes that are in some of the nonroot
>> cgroups created by systemd, namely:
>
> I see.  Thanks for tracking it down.  Yeah, the RT side of things
> isn't too well thought out yet.
>
>> # ps ax -L -o 'pid tid cls rtprio comm'|grep RR
>>   685   723  RR     99 rtkit-daemon
>>   972   979  RR      5 alsa-sink-ALC26
>>   972   982  RR      5 alsa-source-ALC
>>  1594  1597  RR      5 alsa-sink-ALC26
>>  1594  1600  RR      5 alsa-source-ALC
>>
>> So, one solution is to move those processes to the root cgroup,
>> and then it's possible to write '+pids' to cgroup.subtree_control.
>
> You mean '+cpu", right?

D'oh! Yes. I was also doing some tests with the 'pids' controller, and
mistyped. (I see I even manage to mistitle this mail thread :-(.)

>> Is enabling CONFIG_RT_GROUP_SCHED also a solution? (I have
>> not had a chance to test that yet.)
>
> We aren't yet sure about how we should handle RT and haven't enabled
> RT part on cgroup2 yet.  You can test the same scenario in cgroup1 tho
> and would have to configure RT shares all along the hierarchy to the
> leaf cgroup.

Okay. Thanks for the confirmation that this is at least surprising behavior.

>> Anyway, it seems like this should be documented somewhere in the
>> kernel Documentation files, since it may be that others will run
>> into this as well. I'm not quite sure what should be added to the
>> documentation. Do you have some idea?
>
> I think the only thing we can say right now is that RT processes
> should be in the root cgroup.  :(

Okay. (Will you add that to the v2 doc file?)

Cheers,

Michael

--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/