On Sun, May 24, 2020 at 10:00:46AM -0400, Phil Auld wrote: > On Fri, May 22, 2020 at 05:35:24PM -0400 Joel Fernandes wrote: > > On Fri, May 22, 2020 at 02:59:05PM +0200, Peter Zijlstra wrote: > > [..] > > > > > It doens't allow tasks for form their own groups (by for example > > > > > setting > > > > > the key to that of another task). > > > > > > > > So for this, I was thinking of making the prctl pass in an integer. And > > > > 0 > > > > would mean untagged. Does that sound good to you? > > > > > > A TID, I think. If you pass your own TID, you tag yourself as > > > not-sharing. If you tag yourself with another tasks's TID, you can do > > > ptrace tests to see if you're allowed to observe their junk. > > > > But that would require a bunch of tasks agreeing on which TID to tag with. > > For example, if 2 tasks tag with each other's TID, then they would have > > different tags and not share. > > > > What's wrong with passing in an integer instead? In any case, we would do > > the > > CAP_SYS_ADMIN check to limit who can do it. > > > > Also, one thing CGroup interface allows is an external process to set the > > cookie, so I am wondering if we should use sched_setattr(2) instead of, or > > in > > addition to, the prctl(2). That way, we can drop the CGroup interface > > completely. How do you feel about that? > > > > I think it should be an arbitrary 64bit value, in both interfaces to avoid > any potential reuse security issues. > > I think the cgroup interface could be extended not to be a boolean but take > the value. With 0 being untagged as now. > > And sched_setattr could be used to set it on a per task basis.
Yeah, something like this will be needed. > > > > More seriously, the reason I did it this way is the prctl-tagging is a > > > > bit > > > > incompatible with CGroup tagging: > > > > > > > > 1. What happens if 2 tasks are in a tagged CGroup and one of them > > > > changes > > > > their cookie through prctl? Do they still remain in the tagged CGroup > > > > but are > > > > now going to not trust each other? Do they get removed from the CGroup? > > > > This > > > > is why I made the prctl fail with -EBUSY in such cases. In util-clamp's design (which has task-specific attribute and task-group attribute), it seems for that the priority is task-specific value first, then the group one, then the system-wide one. Perhaps a similar design can be adopted for this interface. So probably we should let the per-task interface not fail if the task was already in CGroup and rather prioritize its value first before looking at the group one? Uclamp's comments: * The effective clamp bucket index of a task depends on, by increasing * priority: * - the task specific clamp value, when explicitly requested from userspace * - the task group effective clamp value, for tasks not either in the root * group or in an autogroup * - the system default clamp value, defined by the sysadmin > > > > > > > > 2. What happens if 2 tagged tasks with different cookies are added to a > > > > tagged CGroup? Do we fail the addition of the tasks to the group, or do > > > > we > > > > override their cookie (like I'm doing)? > > > > > > For #2 I think I prefer failure. > > > > > > But having the rationale spelled out in documentation (man-pages for > > > example) is important. > > > > If we drop the CGroup interface, this would avoid both #1 and #2. > > > > I believe both are useful. Personally, I think the per-task setting should > win over the cgroup tagging. In that case #1 just falls out. Cool, this is similar to what I mentioned above. > And #2 pretty > much as well. Nothing would happen to the tagged task as they were added > to the cgroup. They'd keep their explicitly assigned tags and everything > should "just work". There are other reasons to be in a cpu cgroup together > than just the core scheduling tag. Well ok, so there's no reason to fail them the addition to CGroup of a prctl-tagged task then, we can let it succeed but prioritize the task-specific attribute over the group-specific one. > There are a few other edge cases, like if you are in a cgroup, but have > been tagged explicitly with sched_setattr and then get untagged (presumably > by setting 0) do you get the cgroup tag or just stay untagged? I think based > on per-task winning you'd stay untagged. I supposed you could move out and > back in the cgroup to get the tag reapplied (Or maybe the cgroup interface > could just be reused with the same value to re-tag everyone who's untagged). If we maintain a task-specific tag and a group-specific tag, then I think both tags can coexist and the final tag is decided on priority basis mentioned above. So before getting into CGroup, I think first we develop the task-specific tagging mechanism like Peter was suggesting. So let us talk about that. I will reply to the other thread Vineeth started while CC'ing you. In particular, I like Peter's idea about user land passing a TID to share a core with. thanks, - Joel > > > > Cheers, > Phil > > > > thanks, > > > > - Joel > > > > -- >