lkml.org 
[lkml]   [2018]   [Dec]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] sched: fix infinity loop in update_blocked_averages
Hello,

On Fri, Dec 28, 2018 at 10:30:07AM +0100, Vincent Guittot wrote:
> > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> > index d1907506318a..88b9118b5191 100644
> > --- a/kernel/sched/fair.c
> > +++ b/kernel/sched/fair.c
> > @@ -7698,7 +7698,8 @@ static void update_blocked_averages(int cpu)
> > * There can be a lot of idle CPU cgroups. Don't let fully
> > * decayed cfs_rqs linger on the list.
> > */
> > - if (cfs_rq_is_decayed(cfs_rq))
> > + if (cfs_rq_is_decayed(cfs_rq) &&
> > + rq->tmp_alone_branch == &rq->leaf_cfs_rq_list)
> > list_del_leaf_cfs_rq(cfs_rq);
>
> This patch reduces the cases but I don't thinks it's enough because it
> doesn't cover the case of unregister_fair_sched_group()
> And we can still break the ordering of the cfs_rq

So, if unregister_fair_sched_group() can corrupt list, the bug is
there regardless of a9e7f6544b9ce, right?

Is there a reason why we're building a dedicated list for avg
propagation? AFAICS, it's just doing depth first walk, which can be
done without extra space as long as each node has the parent pointer,
which they do. Is the dedicated list an optimization?

Thanks.

--
tejun

\
 
 \ /
  Last update: 2018-12-28 17:55    [W:0.085 / U:12.980 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site