On 14/02/18 11:36, Juri Lelli wrote: > Hi Mathieu, > > On 13/02/18 13:32, Mathieu Poirier wrote: > > No synchronisation mechanism exist between the cpuset subsystem and calls > > to function __sched_setscheduler(). As such it is possible that new root > > domains are created on the cpuset side while a deadline acceptance test > > is carried out in __sched_setscheduler(), leading to a potential oversell > > of CPU bandwidth. > > > > By making available the cpuset_mutex to the core scheduler it is possible > > to prevent situations such as the one described above from happening. > > > > Signed-off-by: Mathieu Poirier <mathieu.poirier@xxxxxxxxxx> > > --- > > [...] > > > diff --git a/kernel/sched/core.c b/kernel/sched/core.c > > index f727c3d0064c..0d8badcf1f0f 100644 > > --- a/kernel/sched/core.c > > +++ b/kernel/sched/core.c > > @@ -4176,6 +4176,13 @@ static int __sched_setscheduler(struct task_struct *p, > > } > > > > /* > > + * Make sure we don't race with the cpuset subsystem where root > > + * domains can be rebuilt or modified while operations like DL > > + * admission checks are carried out. > > + */ > > + cpuset_lock(); > > + > > + /* > > Mmm, I'm afraid we can't do this. __sched_setscheduler might be called > from interrupt contex by normalize_rt_tasks(). Maybe conditionally grabbing it if pi is true could do? I guess we don't care much about domains when sysrq. -- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
