Re: [tip:sched/core] sched/fair: Limit sched_cfs_period_timer loop to avoid hard lockup

[Phil Auld <pauld@redhat.com>]

On Mon, Apr 08, 2019 at 01:06:12PM -0400 Sasha Levin wrote:
> On Mon, Apr 08, 2019 at 01:03:05PM -0400, Phil Auld wrote:
> > On Mon, Apr 08, 2019 at 10:50:26AM -0400 Sasha Levin wrote:
> > > On Mon, Apr 08, 2019 at 09:42:14AM -0400, Phil Auld wrote:
> > > > On Fri, Apr 05, 2019 at 02:15:23PM +0000 Sasha Levin wrote:
> > > > > Hi,
> > > > >
> > > > > [This is an automated email]
> > > > >
> > > > > This commit has been processed because it contains a -stable tag.
> > > > > The stable tag indicates that it's relevant for the following trees: all
> > > > >
> > > > > The bot has tested the following trees: v5.0.6, v4.19.33, v4.14.110, v4.9.167, v4.4.178, v3.18.138.
> > > > >
> > > > > v5.0.6: Failed to apply! Possible dependencies:
> > > > >     c0ad4aa4d841 ("sched/fair: Robustify CFS-bandwidth timer locking")
> > > > >
> > > > > v4.19.33: Failed to apply! Possible dependencies:
> > > > >     c0ad4aa4d841 ("sched/fair: Robustify CFS-bandwidth timer locking")
> > > > >
> > > > > v4.14.110: Failed to apply! Possible dependencies:
> > > > >     c0ad4aa4d841 ("sched/fair: Robustify CFS-bandwidth timer locking")
> > > > >
> > > >
> > > > This is a minor context difference. There is no actual dependency on the
> > > > c0ad4aa4d841 patch.  It would be easy to produce new version that could
> > > > go in these trees. I'm not sure what the right action is in that case.
> > > > Should I spin a new version with the different locking in the context?
> > > 
> > > Please do :)
> > > 
> > 
> > Sure. I'm just not sure how to post it. It only shows up in this tip-bot
> > email and on gitweb. It's not in tip.git and not in Linus' upstream tree.
> > 
> > I've updated the patch at it will apply now to v5.0.6, v4.19.33, v4.14.110,
> > v4.9.167, v4.4.178  all with increasing offsets but nothing else.
> 
> You can either reply to this thread with the patch(es), or just send
> them out and annotate one way or the other that they should go to their
> appropriate stable trees.
>

Okay, I'll do that.  Am I the only one who finds it strange that the commit
exists only in this email and gitweb but not the actual git tree(s)?


> > v3.18.138 won't take it without more work. I'd be inclined to skip that one.
> 
> No problem there.
> 
> 
> --
> Thanks,
> Sasha

--