On Wed, Dec 2, 2020 at 12:02 AM Peter Zijlstra <pet...@infradead.org> wrote:
>
> On Tue, Dec 01, 2020 at 10:18:00PM -0800, Josh Don wrote:
> > Hey Peter,
> >
> > On Wed, Nov 25, 2020 at 5:43 AM Peter Zijlstra <pet...@infradead.org> wrote:
> > >
> > > Why can't the above work by setting 'tag' (that's a terrible name, why
> > > does that still live) in CDE? Have the most specific tag live. Same with
> > > that thread stuff.
> >
> > The motivation is to allow an unprivileged user the ability to
> > configure the trust hierarchy in a way that otherwise wouldn't be
> > possible for a given cgroup hierarchy. For example given a cookie'd
> > hierarchy such as:
> >
> > A
> > / | | \
> > B C D E
> >
> > the user might only want subsets of {B, C, D, E} to share. For
> > instance, the user might only want {B,C} and {D, E} to share. One way
> > to solve this would be to allow the user to write the group cookie
> > directly. However, this interface would need to be restricted to
> > privileged users, since otherwise the cookie could be configured to
> > share with any arbitrary cgroup. The purpose of the 'color' field is
> > to expose a portion of the cookie that can be modified by a
> > non-privileged user in order to achieve this sharing goal.
> >
> > If this doesn't seem like a useful case, I'm happy to drop this patch
> > from the series to unblock it.
>
> Well, the traditional cgroup way of doing that would be to:
>
> A
> / \
> T1 T2
> / \
> B C
>
> And tag T1 if you want B,C to share.
>
> So me the color thing reads like an end-run around the cgroup hierarchy.
Restructuring the cgroup resource hierarchy to incorporate the trust
domains is not necessarily trivial (as is the case for us). I agree
though that that would be the ideal correct solution from the cgroup
hierarchy perspective.
