linux-kernel - Re: Cgroups v2 thread mode "domain invalid" state

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]

Message-ID: <20171222001554.GH1084507@devbig577.frc2.facebook.com>
Date:   Thu, 21 Dec 2017 16:15:54 -0800
From:   Tejun Heo <tj@...nel.org>
To:     "Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>
Cc:     Peter Zijlstra <peterz@...radead.org>, longman@...hat.com,
        lkml <linux-kernel@...r.kernel.org>,
        linux-man <linux-man@...r.kernel.org>,
        "open list:CONTROL GROUP (CGROUP)" <cgroups@...r.kernel.org>
Subject: Re: Cgroups v2 thread mode "domain invalid" state

Hello,

On Wed, Dec 20, 2017 at 09:32:04PM +0100, Michael Kerrisk (man-pages) wrote:
> I did find the July 2017 mail thread
> "[PATCH 5/6] cgroup: implement cgroup v2 thread support"
> (https://marc.info/?t=150025735500001&r=1&w=2)
> where this cgroup type was discussed, but I must admit that I still
> don't get it. Instead of converting cgroups under a threaded subtree
> to "domain invalid" type, why can't they just be turned straight into
> "threaded" type?
> 
> I guess another way of asking this question is: what possibilities
> does manually switching each "domain invalid" cgroup to "threaded"
> allow that wouldn't be allowed by immediately making all of the
> cgroups in a threaded subtree "threaded"?

IIRC, there were two reasons.  (Writing from memory, so I might not be
completely accurate.)

* Consistency w/ the cgroups right under the root cgroup.  Because
  they can be both domains and threadroots, we can't switch the
  children over to thread mode automatically.  Doing that for cgroups
  further down in the hierarchy would be really inconsistent.

* Possible extension to threadmode.  If we figure out how to do mixed
  mode further down in the hierarchy (and if there are actual use
  cases which require that), automatically switching would be really
  confusing.

The invalid state while not the most convenient is straight forward
(only the operations which are explicitly asked are performed) and
keeps the door open for future changes.

Thanks.

-- 
tejun