Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp376767yba; Thu, 16 May 2019 02:16:05 -0700 (PDT) X-Google-Smtp-Source: APXvYqz6HPJIZ/9H78jkqLnMeWDy3F+waJCuifeYi6tVU/D/Ypd5mYJs3+o+CNovhKSNmizqyCSS X-Received: by 2002:a65:450b:: with SMTP id n11mr8009051pgq.174.1557998165511; Thu, 16 May 2019 02:16:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557998165; cv=none; d=google.com; s=arc-20160816; b=NKhUbutK6i5qSxOyHCeM3Tyu/2TqEjLffU4Gsk/jzeFB9UGM5OwnuTJYHKngROHyhr 42rLJn2qthM5LRzw19Zcit3p/pZ5KmttHJ5Lw5ot9p6KSyxJzixsBEmYxsbrZU0C7xxq klvoIY3HE3m5yrMJOwWVdWuKc1Loz/DTCT8oGfcLIW6O1ZOMDPrglMs+i3sf7tfB0wXl 7Dkz9lnBvoo6Ofi0PLe3jX4eNRRtHzesnBaRm2HgD8S3xuK9ewUcXyJ09eqPk/vRNh+q AjH8IuB3OatoA6Htc79/3Rj555i5W9GIqeiGUS8vUrqEOtbKYZGxYMOZGACYiEXjEmOT TERQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=R/mPPOfkRX4/446/WdttDBn36c2HJ4ifYvwcnkjDN6w=; b=vDtR+D2hYo5gAD2MoCk+ws/KaavTpq29HNu5X+ghR4p6xOxvJmzBEETrD1THlqm4Ip q3PWnNT4IP4fkOwwCuupy5U4tI+I9eCtWh/+BtkUvse+G6cdNuDkSZ0CkWCiUOPo+J/7 48oqWSWpPqxsdaSYllR+lnAhSKxBmQCiOT3OiCBCo5nhFFy3djGZAWB2y3GlXgn8rZs1 /RAFTGWzjU96BYnrhTzURzTly810Rc2AE6A1Sf6HpJPbsSCz7pYhxDw+dZLjMJJpXc9T /rPqiCMjEDHnYDJdT6ipyO3mCbBupxArqcBg/I5il8LceshdhGM5oMsiEOWCEIEXVsy2 TAIw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a10si4623785pla.60.2019.05.16.02.15.49; Thu, 16 May 2019 02:16:05 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726707AbfEPJOK (ORCPT + 99 others); Thu, 16 May 2019 05:14:10 -0400 Received: from [192.198.146.188] ([192.198.146.188]:12009 "EHLO E6440.gar.corp.intel.com" rhost-flags-FAIL-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1726336AbfEPJOK (ORCPT ); Thu, 16 May 2019 05:14:10 -0400 X-Greylist: delayed 434 seconds by postgrey-1.27 at vger.kernel.org; Thu, 16 May 2019 05:14:09 EDT Received: from E6440.gar.corp.intel.com (localhost [127.0.0.1]) by E6440.gar.corp.intel.com (Postfix) with ESMTP id 94352C0C87; Thu, 16 May 2019 17:06:53 +0800 (CST) From: Harry Pan To: LKML Cc: gs0622@gmail.com, Harry Pan , Stephen Boyd , Thomas Gleixner , John Stultz Subject: [PATCH] clocksource: Untrust the clocksource watchdog when its interval is too small Date: Thu, 16 May 2019 17:06:51 +0800 Message-Id: <20190516090651.1396-1-harry.pan@intel.com> X-Mailer: git-send-email 2.20.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This patch performs a sanity check on the deviation of the clocksource watchdog, target to reduce false alarm that incorrectly marks current clocksource unstable when there comes discrepancy. Say if there is a discrepancy between the current clocksource and watchdog, validate the watchdog deviation first, if its interval is too small against the expected timer interval, we shall trust the current clocksource. It is identified on some Coffee Lake platform w/ PC10 allowed, when the CPU entered and exited from PC10 (the residency counter is increased), the HPET generates timestamp delay, this causes discrepancy making kernel incorrectly untrust the current clocksource (TSC in this case) and re-select the next clocksource which is the problematic HPET, this eventually causes a user sensible wall clock delay. The HPET timestamp delay shall be tackled in firmware domain in order to properly handle the timer offload between XTAL and RTC when it enters PC10, while this patch is a mitigation to reduce the false alarm of clocksource unstable regardless what clocksources are paired. Link: https://bugzilla.kernel.org/show_bug.cgi?id=203183 Signed-off-by: Harry Pan --- kernel/time/clocksource.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/kernel/time/clocksource.c b/kernel/time/clocksource.c index 3bcc19ceb073..fb0a67827346 100644 --- a/kernel/time/clocksource.c +++ b/kernel/time/clocksource.c @@ -96,6 +96,7 @@ static u64 suspend_start; #ifdef CONFIG_CLOCKSOURCE_WATCHDOG static void clocksource_watchdog_work(struct work_struct *work); static void clocksource_select(void); +static void clocksource_dequeue_watchdog(struct clocksource *cs); static LIST_HEAD(watchdog_list); static struct clocksource *watchdog; @@ -236,6 +237,12 @@ static void clocksource_watchdog(struct timer_list *unused) /* Check the deviation from the watchdog clocksource. */ if (abs(cs_nsec - wd_nsec) > WATCHDOG_THRESHOLD) { + if (wd_nsec < jiffies_to_nsecs(WATCHDOG_INTERVAL) - WATCHDOG_THRESHOLD) { + pr_err("Stop timekeeping watchdog '%s' because expected interval is too small in %lld ns only\n", + watchdog->name, wd_nsec); + clocksource_dequeue_watchdog(cs); + return; + } pr_warn("timekeeping watchdog on CPU%d: Marking clocksource '%s' as unstable because the skew is too large:\n", smp_processor_id(), cs->name); pr_warn(" '%s' wd_now: %llx wd_last: %llx mask: %llx\n", -- 2.20.1