From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932263AbdBGUGB (ORCPT ); Tue, 7 Feb 2017 15:06:01 -0500 Received: from mx1.redhat.com ([209.132.183.28]:32994 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754690AbdBGUF7 (ORCPT ); Tue, 7 Feb 2017 15:05:59 -0500 Message-ID: <1486497952.2096.13.camel@redhat.com> Subject: Re: [PATCH] nohz: Fix possible missing clock reprog after tick soft restart From: Rik van Riel To: Frederic Weisbecker , Thomas Gleixner Cc: LKML , Peter Zijlstra , Wanpeng Li , stable@vger.kernel.org, Ingo Molnar Date: Tue, 07 Feb 2017 15:05:52 -0500 In-Reply-To: <1486485894-29173-1-git-send-email-fweisbec@gmail.com> References: <1486485894-29173-1-git-send-email-fweisbec@gmail.com> Organization: Red Hat, Inc Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Tue, 07 Feb 2017 20:05:55 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2017-02-07 at 17:44 +0100, Frederic Weisbecker wrote: > 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. > > Lets fix this with a ts->next_tick reset on soft tick restart. > > Signed-off-by: Frederic Weisbecker > Cc: Thomas Gleixner > Cc: Wanpeng Li > Cc: Peter Zijlstra > Cc: Rik van Riel > Cc: Ingo Molnar > Cc: stable@vger.kernel.org > Acked-by: Rik van Riel