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] [day] [month] [year] [list]
Message-ID: <d8aa492c-a5b3-46d5-986e-6e6aa5260d21@paulmck-laptop>
Date: Thu, 31 Jul 2025 15:54:39 -0700
From: "Paul E. McKenney" <paulmck@...nel.org>
To: Jiri Wiesner <jwiesner@...e.de>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	John Stultz <jstultz@...gle.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Stephen Boyd <sboyd@...nel.org>, Waiman Long <longman@...hat.com>
Subject: Re: [PATCH] clocksource: Print durations for sync check
 unconditionally

On Thu, Jul 31, 2025 at 06:18:37PM +0200, Jiri Wiesner wrote:
> A typical set of messages that gets printed as a result of the clocksource
> watchdog finding the TSC unstable usually does not contain messages
> indicating CPUs being ahead of or behind the CPU from which the check is
> carried out. That fact suggests that the TSC does not experience time skew
> between CPUs (if the clocksource.verify_n_cpus parameter is set to a
> negative value) but quantitative information is missing.
> 
> The cs_nsec_max value printed by the "CPU %d check durations" message
> actually provides a worst case estimate of the time skew. If all CPUs have
> been checked, the cs_nsec_max value multiplied by 2 is the maximum
> possible time skew between the TSCs of any two CPUs on the system. The
> worst case estimate is derived from two boundary cases:
> 
> 1. No time is consumed to execute instructions between csnow_begin and
> csnow_mid while all the cs_nsec_max time is consumed by the code between
> csnow_mid and csnow_end. In this case, the maximum undetectable time skew
> of a CPU being ahead would be cs_nsec_max.
> 
> 2. All the cs_nsec_max time is consumed to execute instructions between
> csnow_begin and csnow_mid while no time is consumed by the code between
> csnow_mid and csnow_end. In this case, the maximum undetectable time skew
> of a CPU being behind would be cs_nsec_max.
> 
> The worst case estimate assumes a system experiencing a corner case
> consisting of the two boundary cases.
> 
> Always print the "CPU %d check durations" message so that the maximum
> possible time skew measured by the TSC sync check can be compared to the
> time skew measured by the clocksource watchdog.
> 
> Signed-off-by: Jiri Wiesner <jwiesner@...e.de>

Works at this end:

Reviewed-by: Paul E. McKenney <paulmck@...nel.org>

> ---
>  kernel/time/clocksource.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/kernel/time/clocksource.c b/kernel/time/clocksource.c
> index e400fe150f9d..3eeb18233a6b 100644
> --- a/kernel/time/clocksource.c
> +++ b/kernel/time/clocksource.c
> @@ -410,9 +410,8 @@ void clocksource_verify_percpu(struct clocksource *cs)
>  	if (!cpumask_empty(&cpus_behind))
>  		pr_warn("        CPUs %*pbl behind CPU %d for clocksource %s.\n",
>  			cpumask_pr_args(&cpus_behind), testcpu, cs->name);
> -	if (!cpumask_empty(&cpus_ahead) || !cpumask_empty(&cpus_behind))
> -		pr_warn("        CPU %d check durations %lldns - %lldns for clocksource %s.\n",
> -			testcpu, cs_nsec_min, cs_nsec_max, cs->name);
> +	pr_info("        CPU %d check durations %lldns - %lldns for clocksource %s.\n",
> +		testcpu, cs_nsec_min, cs_nsec_max, cs->name);
>  }
>  EXPORT_SYMBOL_GPL(clocksource_verify_percpu);
>  
> -- 
> 2.43.0
> 
> 
> -- 
> Jiri Wiesner
> SUSE Labs

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ