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