A previous patch intended to update both MAX_SKEW_USEC and
CLOCKSOURCE_WATCHDOG_MAX_SKEW_US to 125 microseconds, resulting in a
total tolerable skew per second of 500 microseconds as this value is
doubled prior to being associated with the uncertainty_margin of a
clocksource, and the uncertainty_margin values of two clocksources being
compared are then summed before comparison to the skew.

However, the default value of MAX_SKEW_USEC in the absence of the
Kconfig option was defined as (125 * WATCHDOG_INTERVAL / HZ), which is
(125 * (HZ >> 1)) / HZ, effectively ~ 125/2 microseconds, while
CLOCKSOURCE_WATCHDOG_MAX_SKEW_US was set to 125 microseconds as
intended.

Therefore, align MAX_SKEW_USEC with CLOCKSOURCE_WATCHDOG_MAX_SKEW_US,
setting it to the intended default value of 125 microseconds.

'Fixes: c37e85c135ce ("clocksource: Loosen clocksource watchdog
constraints")'

Signed-off-by: Connor Williamson <connordw@amazon.com>
---
 kernel/time/clocksource.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/time/clocksource.c b/kernel/time/clocksource.c
index e753a0632ac8..bd4aea8db2de 100644
--- a/kernel/time/clocksource.c
+++ b/kernel/time/clocksource.c
@@ -137,7 +137,7 @@ static u64 suspend_start;
 #ifdef CONFIG_CLOCKSOURCE_WATCHDOG_MAX_SKEW_US
 #define MAX_SKEW_USEC	CONFIG_CLOCKSOURCE_WATCHDOG_MAX_SKEW_US
 #else
-#define MAX_SKEW_USEC	(125 * WATCHDOG_INTERVAL / HZ)
+#define MAX_SKEW_USEC	125
 #endif
 
 /*
-- 
2.47.3

On Fri, Mar 13 2026 at 14:29, Connor Williamson wrote:
> A previous patch intended to update both MAX_SKEW_USEC and
> CLOCKSOURCE_WATCHDOG_MAX_SKEW_US to 125 microseconds, resulting in a
> total tolerable skew per second of 500 microseconds as this value is
> doubled prior to being associated with the uncertainty_margin of a
> clocksource, and the uncertainty_margin values of two clocksources being
> compared are then summed before comparison to the skew.
>
> However, the default value of MAX_SKEW_USEC in the absence of the
> Kconfig option was defined as (125 * WATCHDOG_INTERVAL / HZ), which is
> (125 * (HZ >> 1)) / HZ, effectively ~ 125/2 microseconds, while
> CLOCKSOURCE_WATCHDOG_MAX_SKEW_US was set to 125 microseconds as
> intended.

Q: How does that matter?

A: Not at all.

   CLOCKSOURCE_WATCHDOG_MAX_SKEW_US is always defined when
   CLOCKSOURCE_WATCHDOG=y.

IOW, the #else path is simply dead code.

> Therefore, align MAX_SKEW_USEC with CLOCKSOURCE_WATCHDOG_MAX_SKEW_US,
> setting it to the intended default value of 125 microseconds.
>
> 'Fixes: c37e85c135ce ("clocksource: Loosen clocksource watchdog
> constraints")'

Bogus format for the Fixes tag. Please read and follow
Documentation. It's there for a reason.

But that doesn't matter much because this patch fixes clearly nothing.
The only valid "fix" is to delete the dead code and not to polish it,
but that's pretty moot as it is harmless and already scheduled for
removal in 7.1 due to:

  https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?h=timers/core

Thanks,

        tglx

On Fri, Mar 20 2026 at 17:58 (+0100), Thomas Gleixner wrote:
> The only valid "fix" is to delete the dead code and not to polish it,
> but that's pretty moot as it is harmless and already scheduled for
> removal in 7.1 due to:
> 
>   https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?h=timers/core

Please withdraw my patch. Thanks for your response, I wasn't aware that
despite cs->uncertainty_margin being set when CLOCKSOURCE_WATCHDOG=n it
wasn't subsequently being read anywhere upstream. Since this logic will be
removed in v7.1 anyway this patch is indeed pointless.

Apologies for the noise,
Connor

On Mon, Mar 23 2026 at 13:28, connordw@amazon.com wrote:
> On Fri, Mar 20 2026 at 17:58 (+0100), Thomas Gleixner wrote:
>> The only valid "fix" is to delete the dead code and not to polish it,
>> but that's pretty moot as it is harmless and already scheduled for
>> removal in 7.1 due to:
>> 
>>   https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?h=timers/core
>
> Please withdraw my patch. Thanks for your response, I wasn't aware that
> despite cs->uncertainty_margin being set when CLOCKSOURCE_WATCHDOG=n it
> wasn't subsequently being read anywhere upstream. Since this logic will be
> removed in v7.1 anyway this patch is indeed pointless.
>
> Apologies for the noise,

Nothing to apologize for.