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 08:00:49 -0800
From:   Tejun Heo <tj@...nel.org>
To:     "Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>
Cc:     lkml <linux-kernel@...r.kernel.org>,
        Lennart Poettering <lennart@...ttering.net>
Subject: Re: Writing "+pids" to cgroup.subtree_control flie yields EINVAL

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?

> 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.

> 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.  :(

Thanks a lot.

-- 
tejun