Re: [PATCH v1 3/3] cgroup: relax common ancestor restriction for direct descendants
From: Tejun Heo
Date: Thu Jul 21 2016 - 11:08:56 EST
On Thu, Jul 21, 2016 at 08:04:16AM -0700, James Bottomley wrote:
> > I understand what you're trying to achieve but don't think cgroup's
> > filesystem interface can accomodate that. To support that level of
> > automatic delegation, the API should be providing enough isolation so
> > that operations in one domain (user-specific operations) are
> > transparent from the other (system-wide administration), which simply
> > isn't true for cgroupfs. As a simple example, imagine a process
> > being moved to another cgroup racing against the special operations
> > you're describing ahead. Both sides are multi-step operations and
> > there are no ways of synchronizing against each other from kernel
> > side and the outcomes can easily be non-sensical.
> So if I understand, it's not about actually moving the tasks: echoing
> the pid to the tasks file is atomic and we can mediate races there.
Yeah, each operation is atomic but most meaningul operations are
> It's about the debris left behind if the admin (or someone with
> delegated authority) moves the task to a wholly different cgroup.
> Now we have a cgroup directory in the old cgroup, which the current
> task has been removed from, for which the current user has permissions
> and could then move the task back to. Is that the essence of the
That'd be one side. The other side is the one moving. Let's say the
system admin thing wants to move all processe from A proper to B. It
would do that by draining processes from A's procs file into B's and
even that is multistep and can race.