Messages in this thread |  | | Date | Wed, 2 Dec 2020 09:02:11 +0100 | From | Peter Zijlstra <> | Subject | Re: [PATCH -tip 26/32] sched: Add a second-level tag for nested CGroup usecase |
| |
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 <peterz@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.
|  |