From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B2B65C433ED for ; Thu, 29 Apr 2021 07:38:42 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 79C8761440 for ; Thu, 29 Apr 2021 07:38:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231202AbhD2Hj0 (ORCPT ); Thu, 29 Apr 2021 03:39:26 -0400 Received: from mga14.intel.com ([192.55.52.115]:1980 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239762AbhD2HjH (ORCPT ); Thu, 29 Apr 2021 03:39:07 -0400 IronPort-SDR: jUrGf21yTe8sRKnxPPkd1nSS7eh1OpLcjLOwvEh8CoV/Rt2DVr5puR4y9l1NkwoG7QO7ltTYcq sXGmeZYOrt6Q== X-IronPort-AV: E=McAfee;i="6200,9189,9968"; a="196502442" X-IronPort-AV: E=Sophos;i="5.82,258,1613462400"; d="scan'208";a="196502442" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Apr 2021 00:38:21 -0700 IronPort-SDR: qyNJhMyS573341bMtMyQx7/cmndiTpoc0zlhI+GheSQDEwbQVSpGI+WeIO1n2To/9vI8oiR1Qo qqtznY9tO1DQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.82,258,1613462400"; d="scan'208";a="423944954" Received: from shbuild999.sh.intel.com (HELO localhost) ([10.239.147.94]) by fmsmga008.fm.intel.com with ESMTP; 29 Apr 2021 00:38:16 -0700 Date: Thu, 29 Apr 2021 15:38:16 +0800 From: Feng Tang To: Thomas Gleixner Cc: Peter Zijlstra , paulmck@kernel.org, kernel test robot , 0day robot , John Stultz , Stephen Boyd , Jonathan Corbet , Mark Rutland , Marc Zyngier , Andi Kleen , Xing Zhengjun , LKML , lkp@lists.01.org, kernel-team@fb.com, neeraju@codeaurora.org, zhengjun.xing@intel.com, x86@kernel.org, Paolo Bonzini , Borislav Petkov Subject: Re: [clocksource] 8c30ace35d: WARNING:at_kernel/time/clocksource.c:#clocksource_watchdog Message-ID: <20210429073816.GA317@shbuild999.sh.intel.com> References: <87y2d3mo2q.ffs@nanos.tec.linutronix.de> <87a6pimt1f.ffs@nanos.tec.linutronix.de> <871raumjj4.ffs@nanos.tec.linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <871raumjj4.ffs@nanos.tec.linutronix.de> User-Agent: Mutt/1.5.24 (2015-08-30) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Apr 28, 2021 at 07:00:15PM +0200, Thomas Gleixner wrote: > On Wed, Apr 28 2021 at 17:39, Peter Zijlstra wrote: > > On Wed, Apr 28, 2021 at 03:34:52PM +0200, Thomas Gleixner wrote: > >> #4 is the easy case because we can check MSR_TSC_ADJUST to figure out > >> whether something has written to MSR_TSC or MSR_TSC_ADJUST and undo > >> the damage in a sane way. > > > > This is after the fact though; userspace (and kernel space) will have > > observed non-linear time and things will be broken in various subtle and > > hard to tell ways. > > What I observed in the recent past is that _IF_ that happens it's a > small amount of cycles so it's not a given that this can be observed > accross CPUs. But yes, it's daft. Currently when tsc_adjust overriden is detected, the warning msg is "[Firmware Bug]: TSC ADJUST differs: CPU%u %lld --> %lld. Restoring", which is kind of gentle. With Borislav's patch of preventing user space from writing to tsc_adjust msr, the warning could be stronger? Adding something after that like: "Writing to TSC_ADJUST MSR is dangerous, and may cause the lost of your best clocksource: tsc, please check with your BIOS/OS vendors" Thanks, Feng > >> I can live with that and maybe we should have done that 15 years ago > >> instead of trying to work around it at the symptom level. > > > > Anybody that still has runtime BIOS wreckage will then silently suffer > > nonlinear time, doubly so for anybody not having TSC_ADJUST. Are we sure > > we can tell them all to bugger off and buy new hardware? > > > > At the very least we need something like tsc=broken, to explicitly mark > > TSC bad on machines, so that people that see TSC fail on their current > > kernels can continue to use the new kernels. This requires a whole lot > > of care on the part of users though, and will raise a ruckus, because I > > bet a fair number of these people are not even currently aware we're > > disabling TSC for them :/ > > I'm still allowed to dream, right? :) > > Thanks, > > tglx From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============1051997159024129325==" MIME-Version: 1.0 From: Feng Tang To: lkp@lists.01.org Subject: Re: [clocksource] 8c30ace35d: WARNING:at_kernel/time/clocksource.c:#clocksource_watchdog Date: Thu, 29 Apr 2021 15:38:16 +0800 Message-ID: <20210429073816.GA317@shbuild999.sh.intel.com> In-Reply-To: <871raumjj4.ffs@nanos.tec.linutronix.de> List-Id: --===============1051997159024129325== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Wed, Apr 28, 2021 at 07:00:15PM +0200, Thomas Gleixner wrote: > On Wed, Apr 28 2021 at 17:39, Peter Zijlstra wrote: > > On Wed, Apr 28, 2021 at 03:34:52PM +0200, Thomas Gleixner wrote: > >> #4 is the easy case because we can check MSR_TSC_ADJUST to figure out > >> whether something has written to MSR_TSC or MSR_TSC_ADJUST and undo > >> the damage in a sane way. > > > > This is after the fact though; userspace (and kernel space) will have > > observed non-linear time and things will be broken in various subtle and > > hard to tell ways. > = > What I observed in the recent past is that _IF_ that happens it's a > small amount of cycles so it's not a given that this can be observed > accross CPUs. But yes, it's daft. Currently when tsc_adjust overriden is detected, the warning msg is "[Firmware Bug]: TSC ADJUST differs: CPU%u %lld --> %lld. Restoring", which is kind of gentle. With Borislav's patch of preventing user space from writing to tsc_adjust msr, the warning could be stronger? Adding something after that like: = "Writing to TSC_ADJUST MSR is dangerous, and may cause the lost of your best clocksource: tsc, please check with your BIOS/OS vendors" Thanks, Feng > >> I can live with that and maybe we should have done that 15 years ago > >> instead of trying to work around it at the symptom level. > > > > Anybody that still has runtime BIOS wreckage will then silently suffer > > nonlinear time, doubly so for anybody not having TSC_ADJUST. Are we sure > > we can tell them all to bugger off and buy new hardware? > > > > At the very least we need something like tsc=3Dbroken, to explicitly ma= rk > > TSC bad on machines, so that people that see TSC fail on their current > > kernels can continue to use the new kernels. This requires a whole lot > > of care on the part of users though, and will raise a ruckus, because I > > bet a fair number of these people are not even currently aware we're > > disabling TSC for them :/ > = > I'm still allowed to dream, right? :) > = > Thanks, > = > tglx --===============1051997159024129325==--