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 for Android: free password hash cracker in your pocket

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

Message-ID: <20180108160846.GV3668920@devbig577.frc2.facebook.com>
Date:   Mon, 8 Jan 2018 08:08:46 -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, Michael.

On Fri, Dec 22, 2017 at 10:11:00AM +0100, Michael Kerrisk (man-pages) wrote:
> I don't get the above. I mean, if we have the following hierarchy,
> where R is the cgoup v2 mount point:

You're right, I'm probably confused with an earlier variant.  I might
still be forgetting something in this area.  I'll ping back if I can
recall something.

> > * 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.
> 
> The "allowing for future" extensions idea makes some sense to me.
> 
> One other point that occurred to me after I wrote my email yesterday
> was that if the threaded root reverts from being "domain threaded" to
> "domain" (because it no longer has "threaded" children AND either it
> has no member processes or it has no threaded controllers enabled),
> then the "domain invalid" descendants revert to type "domain". I'm not
> sure whether that detail also provides some rationale as to why all
> descendants of the threaded root cgroup aren't automatically converted
> to type "threaded". Any thoughts about that?

Currently, thread mode implementation doesn't allow reverting back to
domain.  The problem there is that it's impossible to tell which
portions of the domain consumptions that are accounted to the threaded
domain (the parent of threaded subtree) belong to the cgroup which is
trying to revert to domain.

But assuming we in the future allow reverting back to domain,
scenarios similar to what you suggested can become problematic.  All
operations always behaving recursively will probably be the only sane
solution but that blocks some possibilities for future changes.

Thanks.

-- 
tejun