linux-kernel - Re: [PATCH v7 clocksource] Do not mark clocks unstable due to delays for v5.13

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]

Date:   Sat, 10 Apr 2021 16:26:44 -0700
From:   "Paul E. McKenney" <paulmck@...nel.org>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     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
Subject: Re: [PATCH v7 clocksource] Do not mark clocks unstable due to delays
 for v5.13

On Sat, Apr 10, 2021 at 10:01:58AM +0200, Thomas Gleixner wrote:
> On Fri, Apr 02 2021 at 15:48, Paul E. McKenney wrote:
> > Hello!
> >
> > If there is a sufficient delay between reading the watchdog clock and the
> > clock under test, the clock under test will be marked unstable through no
> > fault of its own.  This series checks for this, doing limited retries
> > to get a good set of clock reads.  If the clock is marked unstable
> > and is marked as being per-CPU, cross-CPU synchronization is checked.
> > This series also provides delay injection, which may be enabled via
> > kernel boot parameters to test the checking for delays.
> >
> > Note that "sufficient delay" can be provided by SMIs, NMIs, and of course
> > vCPU preemption.
> 
> I buy the vCPU preemption part and TBH guests should not have that
> watchdog thing active at all for exactly this reason.

Agreed, one approch is to enable the the clocksource watchdog only in
the hypervisor, and have some action on the guests triggered when the
host detects clock skew.

This works quite well, at least until something breaks in a way that
messes up clock reads from the guest but not from the host.  And I
am sure that any number of hardware guys will tell me that this just
isn't possible, but if failing hardware operated according to their
expectations, that hardware wouldn't be considered to be failing.
Or it wouldn't be hardware, firmware, or clock-driver bringup, as the
case may be.

> SMI, NMI injecting 62.5ms delay? If that happens then the performance of
> the clocksource is the least of your worries.

I was kind of hoping that you would tell me why the skew must be all the
way up to 62.5ms before the clock is disabled.  The watchdog currently
is quite happy with more than 10% skew between clocks.

100HZ clocks or some such?

							Thanx, Paul