/proc/self/tags
Tejun Heo opened an RFD on the kernel lists titled “cgroup: about multiple hierarchies”—the discussion that eventually became cgroup v2.
I was using cgroups and namespaces in my container tooling. Interface changes affected it directly, so I joined the discussion.
The multiple-hierarchies problem
cgroup v1 allowed every controller to be mounted on its own hierarchy—CPU grouped one way, memory another, block I/O a third. In principle, flexibility. In practice, every process belonged to several trees at once, every tool had to agree with every other tool about which hierarchy meant what, and controllers couldn’t cooperate because they couldn’t assume they saw the same grouping. Heo’s RFD asked, roughly: should this even survive?
The thread’s tension was not unanimity. Serge Hallyn supplied concrete orthogonal-grouping counterexamples and worried about losing hierarchy freedom; Vivek Goyal pointed out that separate hierarchies let an operator leave an expensive controller unused. Even people inclined toward one hierarchy still had an ABI in front of them. Frederic Weisbecker put that trap in one line:
Thing is we have an ABI now and it has been there for a while now
A sentence later:
I’m no big fan of that multiple hierarchies thing either but now I fear we have to support it.
The discussion turned on whether the simplification justified the use cases and compatibility it would remove.
My contribution, in a reply within the RFD, was to question the filesystem-tree interface itself. If the problem is that the control hierarchy and the process hierarchy keep disagreeing, then bind the controls to the process tree directly and flatten the control space into per-process tags:
# my pid?
$ echo $$
123
# what controllers are available for this process?
$ cat /proc/self/tags/TYPE
# create a new `name` base controller
$ touch /proc/self/tags/admin
# explicit assign `admin` 150 shares
$ echo 150 > /proc/self/tags/admin.cpuacct.cpu.shares
# tag will propogate to children
$ echo 1 > /proc/self/tags/admin.cpuacct.cpu.PERSISTENTA tag is created by touching a file under /proc/self/tags/; controller parameters hang off the tag name; persistence across fork is an explicit attribute rather than an accident of which directory your PID landed in. Controllers decide for themselves whether multiple tags per process mean anything, and how lateral or descendant values combine—the question that made multiple hierarchies painful becomes each controller’s local policy instead of global mount topology. No mounted tree, no manager daemon owning a mount point—process-relative names in /proc, where process-relative state already lived. The full message is in the archives.
I soon replied to myself with corrections: one example assigned shares to admin twice where the second should have read users (“s,admin,users,”). About the PRIORITY attribute, I wrote:
maybe redundant, my original reasoning for it escapes me.
The follow-up corrected the example and questioned whether that extra attribute was needed.
The single-hierarchy direction later became the defining shape of cgroup v2. My proposal did not: v2 kept the mounted filesystem tree, and /proc/self/tags stayed a mailing-list message. Given a decade of hindsight, the tree also carried delegation and nesting—containers inside containers—more naturally than flat per-process tags would have.
The earlier namespace question
The RFD wasn’t my first time questioning plumbing on those lists. Eric Biederman’s namespace-file-descriptor work—/proc/<pid>/ns/, setns()—was headed for the 2.6.40 merge window, and I asked whether it weakened isolation:
would it now become possible for
rootto inject stuff into my private namespaces?
I also asked about the existing guarantees and ACLs on the new handles.
Serge Hallyn answered with a counterexample: root in another mount namespace could already reach your private files through /proc/$$/fd/N. The isolation I was worried about protecting had never existed. My reply, in full period voice:
aaah right :-( … there’s always another way isn’t there … curse you Linux for being so flexible! (just kidding baby i love you)
And then the real position, in the same message: I was asking “in the context of OS virt via cgroups + namespaces, eg. LXC et al,” ahead of “a massive overhaul to our crusty sub-2.6.18 infrastructure,” and after years of watching these pieces mature, “it’s starting to feel like ‘the right time’.”
Neither proposal changed the kernel in my direction. The isolation guarantee I assumed was already absent, and a unified cgroup tree had delegation constraints my tag proposal left unresolved. I kept building with both.