Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S945841AbdDTS3I (ORCPT ); Thu, 20 Apr 2017 14:29:08 -0400 Received: from mail-wm0-f66.google.com ([74.125.82.66]:33186 "EHLO mail-wm0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S943114AbdDTS3F (ORCPT ); Thu, 20 Apr 2017 14:29:05 -0400 Date: Thu, 20 Apr 2017 20:29:02 +0200 From: Frederic Weisbecker To: Thomas Gleixner Cc: Ingo Molnar , LKML , Peter Zijlstra , Rik van Riel , James Hartsock , stable@vger.kernel.org, Tim Wright , Pavel Machek Subject: Re: [PATCH 2/2] tick: Make sure tick timer is active when bypassing reprogramming Message-ID: <20170420182900.GE25160@lerouge> References: <1492702230-28462-1-git-send-email-fweisbec@gmail.com> <1492702230-28462-3-git-send-email-fweisbec@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1662 Lines: 42 On Thu, Apr 20, 2017 at 07:56:22PM +0200, Thomas Gleixner wrote: > On Thu, 20 Apr 2017, Frederic Weisbecker wrote: > > > So far we have run into too much troubles with the optimization path > > that skips reprogramming the clock on IRQ exit when the expiration > > deadline hasn't changed. If by accident the cached deadline happens to > > be out of sync with the hardware deadline, the buggy result and its > > cause are hard to investigate. So lets detect and warn about the issue > > early. > > > > Signed-off-by: Frederic Weisbecker > > Cc: Tim Wright > > Cc: Pavel Machek > > Cc: James Hartsock > > Cc: Peter Zijlstra > > Cc: Rik van Riel > > Cc: Thomas Gleixner > > Cc: Ingo Molnar > > --- > > kernel/time/tick-sched.c | 4 +++- > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c > > index 502b320..eb1366e 100644 > > --- a/kernel/time/tick-sched.c > > +++ b/kernel/time/tick-sched.c > > @@ -783,8 +783,10 @@ static ktime_t tick_nohz_stop_sched_tick(struct tick_sched *ts, > > tick = expires; > > > > /* Skip reprogram of event if its not changed */ > > - if (ts->tick_stopped && (expires == ts->next_tick)) > > + if (ts->tick_stopped && (expires == ts->next_tick)) { > > + WARN_ON_ONCE(dev->next_event > ts->next_tick); > > What about handling it proper ? dev->next_event might be KTIME_MAX, > i.e. no more event for the next 500+ years. I thought I handled this case, what I'm I missing? > Thanks, > > tglx