linux-kernel - Re: [PATCH v10 clocksource 3/7] clocksource: Check per-CPU clock synchronization when marked unstable

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: <20210426041235.GT1401198@tassilo.jf.intel.com>
Date:   Sun, 25 Apr 2021 21:12:35 -0700
From:   Andi Kleen <ak@...ux.intel.com>
To:     "Paul E. McKenney" <paulmck@...nel.org>
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, feng.tang@...el.com,
        zhengjun.xing@...el.com, Chris Mason <clm@...com>
Subject: Re: [PATCH v10 clocksource 3/7] clocksource: Check per-CPU clock
 synchronization when marked unstable

On Sun, Apr 25, 2021 at 03:47:04PM -0700, Paul E. McKenney wrote:
> Some sorts of per-CPU clock sources have a history of going out of
> synchronization with each other.  However, this problem has purportedy
> been solved in the past ten years.  Except that it is all too possible
> that the problem has instead simply been made less likely, which might
> mean that some of the occasional "Marking clocksource 'tsc' as unstable"
> messages might be due to desynchronization.  How would anyone know?
> 
> Therefore apply CPU-to-CPU synchronization checking to newly unstable
> clocksource that are marked with the new CLOCK_SOURCE_VERIFY_PERCPU flag.
> Lists of desynchronized CPUs are printed, with the caveat that if it
> is the reporting CPU that is itself desynchronized, it will appear that
> all the other clocks are wrong.  Just like in real life.

Well I could see this causing a gigantic flood of messages then.
Assume I have 300 cores, do I get all those messages 300 times repeated
then? If the console is slow this might end up taking a lot
of CPU time.

And in a larger cluster this might not be uncommon. 

There must be some way to throttle this.

-Andi