Oops, nope, this breaks the build on 4.9 and 4.4-stable kernels, so I'm dropping it there :( greg k-h On Sun, Feb 12, 2017 at 02:15:28PM -0800, gregkh@xxxxxxxxxxxxxxxxxxx wrote: > > This is a note to let you know that I've just added the patch titled > > tick/nohz: Fix possible missing clock reprog after tick soft restart > > to the 4.9-stable tree which can be found at: > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary > > The filename of the patch is: > tick-nohz-fix-possible-missing-clock-reprog-after-tick-soft-restart.patch > and it can be found in the queue-4.9 subdirectory. > > If you, or anyone else, feels it should not be added to the stable tree, > please let <stable@xxxxxxxxxxxxxxx> know about it. > > > >From 7bdb59f1ad474bd7161adc8f923cdef10f2638d1 Mon Sep 17 00:00:00 2001 > From: Frederic Weisbecker <fweisbec@xxxxxxxxx> > Date: Tue, 7 Feb 2017 17:44:54 +0100 > Subject: tick/nohz: Fix possible missing clock reprog after tick soft restart > > From: Frederic Weisbecker <fweisbec@xxxxxxxxx> > > commit 7bdb59f1ad474bd7161adc8f923cdef10f2638d1 upstream. > > ts->next_tick keeps track of the next tick deadline in order to optimize > clock programmation on irq exit and avoid redundant clock device writes. > > Now if ts->next_tick missed an update, we may spuriously miss a clock > reprog later as the nohz code is fooled by an obsolete next_tick value. > > This is what happens here on a specific path: when we observe an > expired timer from the nohz update code on irq exit, we perform a soft > tick restart which simply fires the closest possible tick without > actually exiting the nohz mode and restoring a periodic state. But we > forget to update ts->next_tick accordingly. > > As a result, after the next tick resulting from such soft tick restart, > the nohz code sees a stale value on ts->next_tick which doesn't match > the clock deadline that just expired. If that obsolete ts->next_tick > value happens to collide with the actual next tick deadline to be > scheduled, we may spuriously bypass the clock reprogramming. In the > worst case, the tick may never fire again. > > Fix this with a ts->next_tick reset on soft tick restart. > > Signed-off-by: Frederic Weisbecker <fweisbec@xxxxxxxxx> > Reviewed: Wanpeng Li <wanpeng.li@xxxxxxxxxxx> > Acked-by: Rik van Riel <riel@xxxxxxxxxx> > Cc: Peter Zijlstra <peterz@xxxxxxxxxxxxx> > Link: http://lkml.kernel.org/r/1486485894-29173-1-git-send-email-fweisbec@xxxxxxxxx > Signed-off-by: Thomas Gleixner <tglx@xxxxxxxxxxxxx> > Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> > > --- > kernel/time/tick-sched.c | 5 +++++ > 1 file changed, 5 insertions(+) > > --- a/kernel/time/tick-sched.c > +++ b/kernel/time/tick-sched.c > @@ -730,6 +730,11 @@ static ktime_t tick_nohz_stop_sched_tick > */ > if (delta == 0) { > tick_nohz_restart(ts, now); > + /* > + * Make sure next tick stop doesn't get fooled by past > + * clock deadline > + */ > + ts->next_tick = 0; > goto out; > } > } > > > Patches currently in stable-queue which might be from fweisbec@xxxxxxxxx are > > queue-4.9/tick-nohz-fix-possible-missing-clock-reprog-after-tick-soft-restart.patch > -- > To unsubscribe from this list: send the line "unsubscribe stable" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html