Re: [PATCH v3 0/3] Introduce per-task latency_nice for scheduler hints
From: Qais Yousef
Date: Thu Feb 20 2020 - 10:03:51 EST
On 02/20/20 09:30, chris hyser wrote:
> > The below diff works out well enough in-order to align permission checks
> > with NICE.
> > diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> > index 2bfcff5623f9..ef4a397c9170 100644
> > --- a/kernel/sched/core.c
> > +++ b/kernel/sched/core.c
> > @@ -4878,6 +4878,10 @@ static int __sched_setscheduler(struct task_struct *p,
> > return -EINVAL;
> > if (attr->sched_latency_nice < MIN_LATENCY_NICE)
> > return -EINVAL;
> > + /* Use the same security checks as NICE */
> > + if (attr->sched_latency_nice < p->latency_nice &&
> > + !can_nice(p, attr->sched_latency_nice))
> > + return -EPERM;
> > }
> > if (pi)
> > With the above in effect,
> > A non-root user can only increase the value upto +19, and once increased
> > cannot be decreased. e.g., a user once sets the value latency_nice = 19,
> > the same user cannot set the value latency_nice = 18. This is the same
> > effect as with NICE.
> > Is such permission checks required?
> > Unlike NICE, we are going to use latency_nice for scheduler hints only, and
> > so won't it make more sense to allow a user to increase/decrease the values
> > of their owned tasks?
> Whether called a hint or not, it is a trade-off to reduce latency of select
> tasks at the expense of the throughput of the other tasks in the the system.
Does it actually affect the throughput of the other tasks? I thought this will
allow the scheduler to reduce latencies, for instance, when selecting which cpu
it should land on. I can't see how this could hurt other tasks.
Can you expand on the scenario you have in mind please?
> If any of the other tasks belong to other users, you would presumably
> require permission.
AFAIU security_task_setscheduler() will only allow a change if the task is
changing its own attribute value or has SYS_CAP_NICE.
If you're able to change the attribute of another task, then its not only
latency_nice that's broken here.