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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ