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: <871raxv7kk.ffs@nanos.tec.linutronix.de>
Date:   Mon, 26 Apr 2021 09:16:59 +0200
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Andi Kleen <ak@...ux.intel.com>,
        "Paul E. McKenney" <paulmck@...nel.org>
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,
        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 21:12, Andi Kleen wrote:

> 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.

Exactly 4 pr_warn() lines in dmesg which are emitted exactly once when
the TSC deviates from the watchdog where three of them print a cpumask
are really a gigantic flood of messsages.

Thanks,

        tglx