linux-kernel - Re: [PATCH v10 clocksource 6/7] clocksource: Forgive tsc

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20210426182652.GE975577@paulmck-ThinkPad-P17-Gen-1>
Date:   Mon, 26 Apr 2021 11:26:52 -0700
From:   "Paul E. McKenney" <paulmck@...nel.org>
To:     Feng Tang <feng.tang@...el.com>
Cc:     tglx@...utronix.de, linux-kernel@...r.kernel.org,
        john.stultz@...aro.org, sboyd@...nel.org, corbet@....net,
        Mark.Rutland@....com, maz@...nel.org, kernel-team@...com,
        neeraju@...eaurora.org, ak@...ux.intel.com,
        zhengjun.xing@...el.com,
        Xing Zhengjun <zhengjun.xing@...ux.intel.com>
Subject: Re: [PATCH v10 clocksource 6/7] clocksource: Forgive tsc_early
 pre-calibration drift

On Mon, Apr 26, 2021 at 11:36:05PM +0800, Feng Tang wrote:
> On Mon, Apr 26, 2021 at 08:25:29AM -0700, Paul E. McKenney wrote:
> > On Mon, Apr 26, 2021 at 11:01:27PM +0800, Feng Tang wrote:
> > > Hi Paul,
> > > 
> > > On Sun, Apr 25, 2021 at 03:47:07PM -0700, Paul E. McKenney wrote:
> > > > Because the x86 tsc_early clocksource is given a quick and semi-accurate
> > > > calibration (by design!), it might have drift rates well in excess of
> > > > the 0.1% limit that is in the process of being adopted.
> > > > 
> > > > Therefore, add a max_drift field to the clocksource structure that, when
> > > > non-zero, specifies the maximum allowable drift rate in nanoseconds over
> > > > a half-second period.  The tsc_early clocksource initializes this to five
> > > > miliseconds, which corresponds to the 1% drift rate limit suggested by
> > > > Xing Zhengjun.  This max_drift field is intended only for early boot,
> > > > so clocksource_watchdog() splats if it encounters a non-zero value in
> > > > this field more than 60 seconds after boot, inspired by a suggestion by
> > > > Thomas Gleixner.
> > > > 
> > > > This was tested by setting the clocksource_tsc ->max_drift field to 1,
> > > > which, as expected, resulted in a clock-skew event.
> > > 
> > > We've run the same last for this v10, and those 'unstable' thing [1] can
> > > not be reproduced!
> > 
> > Good to hear!  ;-)
> > 
> > > We've reported one case that tsc can be wrongly judged as 'unstable'
> > > by 'refined-jiffies' watchdog [1], while reducing the threshold could
> > > make it easier to be triggered.
> > > 
> > > It could be reproduced on the a plaform with a 115200 serial console,
> > > and hpet been disabled (several x86 platforms has this), add 
> > > 'initcall_debug' cmdline parameter to get more debug message, we can
> > > see:
> > > 
> > > [    1.134197] clocksource: timekeeping watchdog on CPU1: Marking clocksource 'tsc-early' as unstable because the skew is too large:
> > > [    1.134214] clocksource:                       'refined-jiffies' wd_nesc: 500000000 wd_now: ffff8b35 wd_last: ffff8b03 mask: ffffffff
> > > [    1.134217] clocksource:                       'tsc-early' cs_nsec: 507537855 cs_now: 4e63c9d09 cs_last: 4bebd81f5 mask: ffffffffffffffff
> > > [    1.134220] clocksource:                       No current clocksource.
> > > [    1.134222] tsc: Marking TSC unstable due to clocksource watchdog
> > 
> > Just to make sure I understand: "could be reproduced" as in this is the
> > result from v9, and v10 avoids this, correct?
> 
> Sorry I didn't make it clear. This is a rarely happened case, and can
> be reproduced with upstream kerenl, which has 62.5 ms threshold. 6/7 &
> 7/7 patch of reducing the threshold can make it easier to be triggered.

Ah, OK, so this could be considered to be a benefit of this series, then.

Does this happen only for tsc-early, or for tsc as well?

Has it already been triggered on v10 of this series?  (I understand that
it certainly should be easier to trigger, just curious whether this has
already happened.)

							Thanx, Paul