FAILED: patch "[PATCH] clocksource: Make negative motion detection more robust" failed to apply to 6.12-stable tree

FAILED: patch "[PATCH] clocksource: Make negative motion detection more robust" failed to apply to 6.12-stable tree

[gregkh]

The patch below does not apply to the 6.12-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable@vger.kernel.org>.

To reproduce the conflict and resubmit, you may use the following commands:

git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.12.y
git checkout FETCH_HEAD
git cherry-pick -x 76031d9536a076bf023bedbdb1b4317fc801dd67
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<stable@vger.kernel.org>' --in-reply-to '2024121203-griminess-blah-4e97@gregkh' --subject-prefix 'PATCH 6.12.y' HEAD^..

Possible dependencies:



thanks,

greg k-h

------------------ original commit in Linus's tree ------------------

From 76031d9536a076bf023bedbdb1b4317fc801dd67 Mon Sep 17 00:00:00 2001
From: Thomas Gleixner <tglx@linutronix.de>
Date: Tue, 3 Dec 2024 11:16:30 +0100
Subject: [PATCH] clocksource: Make negative motion detection more robust

Guenter reported boot stalls on a emulated ARM 32-bit platform, which has a
24-bit wide clocksource.

It turns out that the calculated maximal idle time, which limits idle
sleeps to prevent clocksource wrap arounds, is close to the point where the
negative motion detection triggers.

  max_idle_ns:                    597268854 ns
  negative motion tripping point: 671088640 ns

If the idle wakeup is delayed beyond that point, the clocksource
advances far enough to trigger the negative motion detection. This
prevents the clock to advance and in the worst case the system stalls
completely if the consecutive sleeps based on the stale clock are
delayed as well.

Cure this by calculating a more robust cut-off value for negative motion,
which covers 87.5% of the actual clocksource counter width. Compare the
delta against this value to catch negative motion. This is specifically for
clock sources with a small counter width as their wrap around time is close
to the half counter width. For clock sources with wide counters this is not
a problem because the maximum idle time is far from the half counter width
due to the math overflow protection constraints.

For the case at hand this results in a tripping point of 1174405120ns.

Note, that this cannot prevent issues when the delay exceeds the 87.5%
margin, but that's not different from the previous unchecked version which
allowed arbitrary time jumps.

Systems with small counter width are prone to invalid results, but this
problem is unlikely to be seen on real hardware. If such a system
completely stalls for more than half a second, then there are other more
urgent problems than the counter wrapping around.

Fixes: c163e40af9b2 ("timekeeping: Always check for negative motion")
Reported-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Link: https://lore.kernel.org/all/8734j5ul4x.ffs@tglx
Closes: https://lore.kernel.org/all/387b120b-d68a-45e8-b6ab-768cd95d11c2@roeck-us.net

diff --git a/include/linux/clocksource.h b/include/linux/clocksource.h
index ef1b16da6ad5..65b7c41471c3 100644
--- a/include/linux/clocksource.h
+++ b/include/linux/clocksource.h
@@ -49,6 +49,7 @@ struct module;
  * @archdata:		Optional arch-specific data
  * @max_cycles:		Maximum safe cycle value which won't overflow on
  *			multiplication
+ * @max_raw_delta:	Maximum safe delta value for negative motion detection
  * @name:		Pointer to clocksource name
  * @list:		List head for registration (internal)
  * @freq_khz:		Clocksource frequency in khz.
@@ -109,6 +110,7 @@ struct clocksource {
 	struct arch_clocksource_data archdata;
 #endif
 	u64			max_cycles;
+	u64			max_raw_delta;
 	const char		*name;
 	struct list_head	list;
 	u32			freq_khz;
diff --git a/kernel/time/clocksource.c b/kernel/time/clocksource.c
index aab6472853fa..7304d7cf47f2 100644
--- a/kernel/time/clocksource.c
+++ b/kernel/time/clocksource.c
@@ -24,7 +24,7 @@ static void clocksource_enqueue(struct clocksource *cs);
 
 static noinline u64 cycles_to_nsec_safe(struct clocksource *cs, u64 start, u64 end)
 {
-	u64 delta = clocksource_delta(end, start, cs->mask);
+	u64 delta = clocksource_delta(end, start, cs->mask, cs->max_raw_delta);
 
 	if (likely(delta < cs->max_cycles))
 		return clocksource_cyc2ns(delta, cs->mult, cs->shift);
@@ -993,6 +993,15 @@ static inline void clocksource_update_max_deferment(struct clocksource *cs)
 	cs->max_idle_ns = clocks_calc_max_nsecs(cs->mult, cs->shift,
 						cs->maxadj, cs->mask,
 						&cs->max_cycles);
+
+	/*
+	 * Threshold for detecting negative motion in clocksource_delta().
+	 *
+	 * Allow for 0.875 of the counter width so that overly long idle
+	 * sleeps, which go slightly over mask/2, do not trigger the
+	 * negative motion detection.
+	 */
+	cs->max_raw_delta = (cs->mask >> 1) + (cs->mask >> 2) + (cs->mask >> 3);
 }
 
 static struct clocksource *clocksource_find_best(bool oneshot, bool skipcur)
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index 0ca85ff4fbb4..3d128825d343 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -755,7 +755,8 @@ static void timekeeping_forward_now(struct timekeeper *tk)
 	u64 cycle_now, delta;
 
 	cycle_now = tk_clock_read(&tk->tkr_mono);
-	delta = clocksource_delta(cycle_now, tk->tkr_mono.cycle_last, tk->tkr_mono.mask);
+	delta = clocksource_delta(cycle_now, tk->tkr_mono.cycle_last, tk->tkr_mono.mask,
+				  tk->tkr_mono.clock->max_raw_delta);
 	tk->tkr_mono.cycle_last = cycle_now;
 	tk->tkr_raw.cycle_last  = cycle_now;
 
@@ -2230,7 +2231,8 @@ static bool timekeeping_advance(enum timekeeping_adv_mode mode)
 		return false;
 
 	offset = clocksource_delta(tk_clock_read(&tk->tkr_mono),
-				   tk->tkr_mono.cycle_last, tk->tkr_mono.mask);
+				   tk->tkr_mono.cycle_last, tk->tkr_mono.mask,
+				   tk->tkr_mono.clock->max_raw_delta);
 
 	/* Check if there's really nothing to do */
 	if (offset < real_tk->cycle_interval && mode == TK_ADV_TICK)
diff --git a/kernel/time/timekeeping_internal.h b/kernel/time/timekeeping_internal.h
index 63e600e943a7..8c9079108ffb 100644
--- a/kernel/time/timekeeping_internal.h
+++ b/kernel/time/timekeeping_internal.h
@@ -30,15 +30,15 @@ static inline void timekeeping_inc_mg_floor_swaps(void)
 
 #endif
 
-static inline u64 clocksource_delta(u64 now, u64 last, u64 mask)
+static inline u64 clocksource_delta(u64 now, u64 last, u64 mask, u64 max_delta)
 {
 	u64 ret = (now - last) & mask;
 
 	/*
-	 * Prevent time going backwards by checking the MSB of mask in
-	 * the result. If set, return 0.
+	 * Prevent time going backwards by checking the result against
+	 * @max_delta. If greater, return 0.
 	 */
-	return ret & ~(mask >> 1) ? 0 : ret;
+	return ret > max_delta ? 0 : ret;
 }
 
 /* Semi public for serialization of non timekeeper VDSO updates. */

Re: FAILED: patch "[PATCH] clocksource: Make negative motion detection more robust" failed to apply to 6.12-stable tree

[Thomas Gleixner]

On Thu, Dec 12 2024 at 14:03, gregkh@linuxfoundation.org wrote:
> The patch below does not apply to the 6.12-stable tree.
> If someone wants it applied there, or to any other stable or longterm
> tree, then please email the backport, including the original git commit
> id to <stable@vger.kernel.org>.
>
> To reproduce the conflict and resubmit, you may use the following commands:
>
> git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.12.y
> git checkout FETCH_HEAD
> git cherry-pick -x 76031d9536a076bf023bedbdb1b4317fc801dd67
> # <resolve conflicts, build, test, etc.>
> git commit -s
> git send-email --to '<stable@vger.kernel.org>' --in-reply-to '2024121203-griminess-blah-4e97@gregkh' --subject-prefix 'PATCH 6.12.y' HEAD^..
>
> Possible dependencies:
>

There clearly is a dependency:

> From 76031d9536a076bf023bedbdb1b4317fc801dd67 Mon Sep 17 00:00:00 2001
> From: Thomas Gleixner <tglx@linutronix.de>
> Date: Tue, 3 Dec 2024 11:16:30 +0100
> Subject: [PATCH] clocksource: Make negative motion detection more robust

<snip>

> Fixes: c163e40af9b2 ("timekeeping: Always check for negative motion")

This was merged in the 6.13 merge window into Linus tree and not
backported to 6.12.y according to my clone of the stable tree.

AI went sideways?

But I don't think these two commits are necessarily stable material,
though I don't have a strong opinion on it. If c163e40af9b2 is
backported, then it has it's own large dependency chain on pre 6.10
kernels...

Thanks,

        tglx

Re: FAILED: patch "[PATCH] clocksource: Make negative motion detection more robust" failed to apply to 6.12-stable tree

[Greg KH]

On Thu, Dec 12, 2024 at 02:58:42PM +0100, Thomas Gleixner wrote:
> On Thu, Dec 12 2024 at 14:03, gregkh@linuxfoundation.org wrote:
> > The patch below does not apply to the 6.12-stable tree.
> > If someone wants it applied there, or to any other stable or longterm
> > tree, then please email the backport, including the original git commit
> > id to <stable@vger.kernel.org>.
> >
> > To reproduce the conflict and resubmit, you may use the following commands:
> >
> > git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.12.y
> > git checkout FETCH_HEAD
> > git cherry-pick -x 76031d9536a076bf023bedbdb1b4317fc801dd67
> > # <resolve conflicts, build, test, etc.>
> > git commit -s
> > git send-email --to '<stable@vger.kernel.org>' --in-reply-to '2024121203-griminess-blah-4e97@gregkh' --subject-prefix 'PATCH 6.12.y' HEAD^..
> >
> > Possible dependencies:
> >
> 
> There clearly is a dependency:
> 
> > From 76031d9536a076bf023bedbdb1b4317fc801dd67 Mon Sep 17 00:00:00 2001
> > From: Thomas Gleixner <tglx@linutronix.de>
> > Date: Tue, 3 Dec 2024 11:16:30 +0100
> > Subject: [PATCH] clocksource: Make negative motion detection more robust
> 
> <snip>
> 
> > Fixes: c163e40af9b2 ("timekeeping: Always check for negative motion")
> 
> This was merged in the 6.13 merge window into Linus tree and not
> backported to 6.12.y according to my clone of the stable tree.
> 
> AI went sideways?

Nope, that commit is now in all of the stable queues, which is why I
added this backport.  Or attempted to.

> But I don't think these two commits are necessarily stable material,
> though I don't have a strong opinion on it. If c163e40af9b2 is
> backported, then it has it's own large dependency chain on pre 6.10
> kernels...

It's in the queues for some reason, let me figure out why...

Re: FAILED: patch "[PATCH] clocksource: Make negative motion detection more robust" failed to apply to 6.12-stable tree

[Greg KH]

On Thu, Dec 12, 2024 at 03:17:03PM +0100, Greg KH wrote:
> On Thu, Dec 12, 2024 at 02:58:42PM +0100, Thomas Gleixner wrote:
> > On Thu, Dec 12 2024 at 14:03, gregkh@linuxfoundation.org wrote:
> > > The patch below does not apply to the 6.12-stable tree.
> > > If someone wants it applied there, or to any other stable or longterm
> > > tree, then please email the backport, including the original git commit
> > > id to <stable@vger.kernel.org>.
> > >
> > > To reproduce the conflict and resubmit, you may use the following commands:
> > >
> > > git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.12.y
> > > git checkout FETCH_HEAD
> > > git cherry-pick -x 76031d9536a076bf023bedbdb1b4317fc801dd67
> > > # <resolve conflicts, build, test, etc.>
> > > git commit -s
> > > git send-email --to '<stable@vger.kernel.org>' --in-reply-to '2024121203-griminess-blah-4e97@gregkh' --subject-prefix 'PATCH 6.12.y' HEAD^..
> > >
> > > Possible dependencies:
> > >
> > 
> > There clearly is a dependency:
> > 
> > > From 76031d9536a076bf023bedbdb1b4317fc801dd67 Mon Sep 17 00:00:00 2001
> > > From: Thomas Gleixner <tglx@linutronix.de>
> > > Date: Tue, 3 Dec 2024 11:16:30 +0100
> > > Subject: [PATCH] clocksource: Make negative motion detection more robust
> > 
> > <snip>
> > 
> > > Fixes: c163e40af9b2 ("timekeeping: Always check for negative motion")
> > 
> > This was merged in the 6.13 merge window into Linus tree and not
> > backported to 6.12.y according to my clone of the stable tree.
> > 
> > AI went sideways?
> 
> Nope, that commit is now in all of the stable queues, which is why I
> added this backport.  Or attempted to.
> 
> > But I don't think these two commits are necessarily stable material,
> > though I don't have a strong opinion on it. If c163e40af9b2 is
> > backported, then it has it's own large dependency chain on pre 6.10
> > kernels...
> 
> It's in the queues for some reason, let me figure out why...

Ah, it was an AUTOSEL thing, I'll go drop it from all queues except
6.12.y for now, thanks.

But, for 6.12.y, we want this fixup too, right?

greg k-h

Re: FAILED: patch "[PATCH] clocksource: Make negative motion detection more robust" failed to apply to 6.12-stable tree

[Thomas Gleixner]

On Thu, Dec 12 2024 at 15:18, Greg KH wrote:
> On Thu, Dec 12, 2024 at 03:17:03PM +0100, Greg KH wrote:
>> > But I don't think these two commits are necessarily stable material,
>> > though I don't have a strong opinion on it. If c163e40af9b2 is
>> > backported, then it has it's own large dependency chain on pre 6.10
>> > kernels...
>> 
>> It's in the queues for some reason, let me figure out why...
>
> Ah, it was an AUTOSEL thing, I'll go drop it from all queues except
> 6.12.y for now, thanks.
>
> But, for 6.12.y, we want this fixup too, right?

If you have c163e40af9b2 pulled back into 6.12.y, then yes. I don't know
why this actually rejects. I just did

git-cherry-pick c163e40af9b2
git-cherry-pick 51f109e92935

on top of v6.12.4 and that just worked fine.

Thanks,

        tglx

Re: FAILED: patch "[PATCH] clocksource: Make negative motion detection more robust" failed to apply to 6.12-stable tree

[Greg KH]

On Thu, Dec 12, 2024 at 03:32:24PM +0100, Thomas Gleixner wrote:
> On Thu, Dec 12 2024 at 15:18, Greg KH wrote:
> > On Thu, Dec 12, 2024 at 03:17:03PM +0100, Greg KH wrote:
> >> > But I don't think these two commits are necessarily stable material,
> >> > though I don't have a strong opinion on it. If c163e40af9b2 is
> >> > backported, then it has it's own large dependency chain on pre 6.10
> >> > kernels...
> >> 
> >> It's in the queues for some reason, let me figure out why...
> >
> > Ah, it was an AUTOSEL thing, I'll go drop it from all queues except
> > 6.12.y for now, thanks.
> >
> > But, for 6.12.y, we want this fixup too, right?
> 
> If you have c163e40af9b2 pulled back into 6.12.y, then yes. I don't know
> why this actually rejects. I just did
> 
> git-cherry-pick c163e40af9b2
> git-cherry-pick 51f109e92935
> 
> on top of v6.12.4 and that just worked fine.

The build breaks :(

Re: FAILED: patch "[PATCH] clocksource: Make negative motion detection more robust" failed to apply to 6.12-stable tree

[Greg KH]

On Thu, Dec 12, 2024 at 03:35:14PM +0100, Greg KH wrote:
> On Thu, Dec 12, 2024 at 03:32:24PM +0100, Thomas Gleixner wrote:
> > On Thu, Dec 12 2024 at 15:18, Greg KH wrote:
> > > On Thu, Dec 12, 2024 at 03:17:03PM +0100, Greg KH wrote:
> > >> > But I don't think these two commits are necessarily stable material,
> > >> > though I don't have a strong opinion on it. If c163e40af9b2 is
> > >> > backported, then it has it's own large dependency chain on pre 6.10
> > >> > kernels...
> > >> 
> > >> It's in the queues for some reason, let me figure out why...
> > >
> > > Ah, it was an AUTOSEL thing, I'll go drop it from all queues except
> > > 6.12.y for now, thanks.
> > >
> > > But, for 6.12.y, we want this fixup too, right?
> > 
> > If you have c163e40af9b2 pulled back into 6.12.y, then yes. I don't know
> > why this actually rejects. I just did
> > 
> > git-cherry-pick c163e40af9b2
> > git-cherry-pick 51f109e92935
> > 
> > on top of v6.12.4 and that just worked fine.
> 
> The build breaks :(

To be specific:

kernel/time/timekeeping.c: In function ‘timekeeping_debug_get_ns’:
kernel/time/timekeeping.c:263:17: error: too few arguments to function ‘clocksource_delta’
  263 |         delta = clocksource_delta(now, last, mask);
      |                 ^~~~~~~~~~~~~~~~~
In file included from kernel/time/timekeeping.c:30:

Re: FAILED: patch "[PATCH] clocksource: Make negative motion detection more robust" failed to apply to 6.12-stable tree

[Thomas Gleixner]

On Thu, Dec 12 2024 at 15:37, Greg KH wrote:
> On Thu, Dec 12, 2024 at 03:35:14PM +0100, Greg KH wrote:
>> On Thu, Dec 12, 2024 at 03:32:24PM +0100, Thomas Gleixner wrote:
>> > On Thu, Dec 12 2024 at 15:18, Greg KH wrote:
>> > > On Thu, Dec 12, 2024 at 03:17:03PM +0100, Greg KH wrote:
>> > >> > But I don't think these two commits are necessarily stable material,
>> > >> > though I don't have a strong opinion on it. If c163e40af9b2 is
>> > >> > backported, then it has it's own large dependency chain on pre 6.10
>> > >> > kernels...
>> > >> 
>> > >> It's in the queues for some reason, let me figure out why...
>> > >
>> > > Ah, it was an AUTOSEL thing, I'll go drop it from all queues except
>> > > 6.12.y for now, thanks.
>> > >
>> > > But, for 6.12.y, we want this fixup too, right?
>> > 
>> > If you have c163e40af9b2 pulled back into 6.12.y, then yes. I don't know
>> > why this actually rejects. I just did
>> > 
>> > git-cherry-pick c163e40af9b2
>> > git-cherry-pick 51f109e92935
>> > 
>> > on top of v6.12.4 and that just worked fine.
>> 
>> The build breaks :(
>
> To be specific:
>
> kernel/time/timekeeping.c: In function ‘timekeeping_debug_get_ns’:
> kernel/time/timekeeping.c:263:17: error: too few arguments to function ‘clocksource_delta’
>   263 |         delta = clocksource_delta(now, last, mask);
>       |                 ^~~~~~~~~~~~~~~~~
> In file included from kernel/time/timekeeping.c:30:

Ah. You also need:

d44d26987bb3 ("timekeeping: Remove CONFIG_DEBUG_TIMEKEEPING")

which in turn does not apply cleanly and needs the backport
below. *shrug*

Thanks,

        tglx
---
diff --git a/arch/riscv/configs/defconfig b/arch/riscv/configs/defconfig
index 2341393cfac1..26c01b9e3434 100644
--- a/arch/riscv/configs/defconfig
+++ b/arch/riscv/configs/defconfig
@@ -301,7 +301,6 @@ CONFIG_DEBUG_MEMORY_INIT=y
 CONFIG_DEBUG_PER_CPU_MAPS=y
 CONFIG_SOFTLOCKUP_DETECTOR=y
 CONFIG_WQ_WATCHDOG=y
-CONFIG_DEBUG_TIMEKEEPING=y
 CONFIG_DEBUG_RT_MUTEXES=y
 CONFIG_DEBUG_SPINLOCK=y
 CONFIG_DEBUG_MUTEXES=y
diff --git a/include/linux/timekeeper_internal.h b/include/linux/timekeeper_internal.h
index 902c20ef495a..715e0919972e 100644
--- a/include/linux/timekeeper_internal.h
+++ b/include/linux/timekeeper_internal.h
@@ -68,9 +68,6 @@ struct tk_read_base {
  *			shifted nano seconds.
  * @ntp_error_shift:	Shift conversion between clock shifted nano seconds and
  *			ntp shifted nano seconds.
- * @last_warning:	Warning ratelimiter (DEBUG_TIMEKEEPING)
- * @underflow_seen:	Underflow warning flag (DEBUG_TIMEKEEPING)
- * @overflow_seen:	Overflow warning flag (DEBUG_TIMEKEEPING)
  *
  * Note: For timespec(64) based interfaces wall_to_monotonic is what
  * we need to add to xtime (or xtime corrected for sub jiffy times)
@@ -124,18 +121,6 @@ struct timekeeper {
 	u32			ntp_err_mult;
 	/* Flag used to avoid updating NTP twice with same second */
 	u32			skip_second_overflow;
-#ifdef CONFIG_DEBUG_TIMEKEEPING
-	long			last_warning;
-	/*
-	 * These simple flag variables are managed
-	 * without locks, which is racy, but they are
-	 * ok since we don't really care about being
-	 * super precise about how many events were
-	 * seen, just that a problem was observed.
-	 */
-	int			underflow_seen;
-	int			overflow_seen;
-#endif
 };
 
 #ifdef CONFIG_GENERIC_TIME_VSYSCALL
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index 1f003247b89b..96933082431f 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -195,97 +195,6 @@ static inline u64 tk_clock_read(const struct tk_read_base *tkr)
 	return clock->read(clock);
 }
 
-#ifdef CONFIG_DEBUG_TIMEKEEPING
-#define WARNING_FREQ (HZ*300) /* 5 minute rate-limiting */
-
-static void timekeeping_check_update(struct timekeeper *tk, u64 offset)
-{
-
-	u64 max_cycles = tk->tkr_mono.clock->max_cycles;
-	const char *name = tk->tkr_mono.clock->name;
-
-	if (offset > max_cycles) {
-		printk_deferred("WARNING: timekeeping: Cycle offset (%lld) is larger than allowed by the '%s' clock's max_cycles value (%lld): time overflow danger\n",
-				offset, name, max_cycles);
-		printk_deferred("         timekeeping: Your kernel is sick, but tries to cope by capping time updates\n");
-	} else {
-		if (offset > (max_cycles >> 1)) {
-			printk_deferred("INFO: timekeeping: Cycle offset (%lld) is larger than the '%s' clock's 50%% safety margin (%lld)\n",
-					offset, name, max_cycles >> 1);
-			printk_deferred("      timekeeping: Your kernel is still fine, but is feeling a bit nervous\n");
-		}
-	}
-
-	if (tk->underflow_seen) {
-		if (jiffies - tk->last_warning > WARNING_FREQ) {
-			printk_deferred("WARNING: Underflow in clocksource '%s' observed, time update ignored.\n", name);
-			printk_deferred("         Please report this, consider using a different clocksource, if possible.\n");
-			printk_deferred("         Your kernel is probably still fine.\n");
-			tk->last_warning = jiffies;
-		}
-		tk->underflow_seen = 0;
-	}
-
-	if (tk->overflow_seen) {
-		if (jiffies - tk->last_warning > WARNING_FREQ) {
-			printk_deferred("WARNING: Overflow in clocksource '%s' observed, time update capped.\n", name);
-			printk_deferred("         Please report this, consider using a different clocksource, if possible.\n");
-			printk_deferred("         Your kernel is probably still fine.\n");
-			tk->last_warning = jiffies;
-		}
-		tk->overflow_seen = 0;
-	}
-}
-
-static inline u64 timekeeping_cycles_to_ns(const struct tk_read_base *tkr, u64 cycles);
-
-static inline u64 timekeeping_debug_get_ns(const struct tk_read_base *tkr)
-{
-	struct timekeeper *tk = &tk_core.timekeeper;
-	u64 now, last, mask, max, delta;
-	unsigned int seq;
-
-	/*
-	 * Since we're called holding a seqcount, the data may shift
-	 * under us while we're doing the calculation. This can cause
-	 * false positives, since we'd note a problem but throw the
-	 * results away. So nest another seqcount here to atomically
-	 * grab the points we are checking with.
-	 */
-	do {
-		seq = read_seqcount_begin(&tk_core.seq);
-		now = tk_clock_read(tkr);
-		last = tkr->cycle_last;
-		mask = tkr->mask;
-		max = tkr->clock->max_cycles;
-	} while (read_seqcount_retry(&tk_core.seq, seq));
-
-	delta = clocksource_delta(now, last, mask);
-
-	/*
-	 * Try to catch underflows by checking if we are seeing small
-	 * mask-relative negative values.
-	 */
-	if (unlikely((~delta & mask) < (mask >> 3)))
-		tk->underflow_seen = 1;
-
-	/* Check for multiplication overflows */
-	if (unlikely(delta > max))
-		tk->overflow_seen = 1;
-
-	/* timekeeping_cycles_to_ns() handles both under and overflow */
-	return timekeeping_cycles_to_ns(tkr, now);
-}
-#else
-static inline void timekeeping_check_update(struct timekeeper *tk, u64 offset)
-{
-}
-static inline u64 timekeeping_debug_get_ns(const struct tk_read_base *tkr)
-{
-	BUG();
-}
-#endif
-
 /**
  * tk_setup_internals - Set up internals to use clocksource clock.
  *
@@ -390,19 +299,11 @@ static inline u64 timekeeping_cycles_to_ns(const struct tk_read_base *tkr, u64 c
 	return ((delta * tkr->mult) + tkr->xtime_nsec) >> tkr->shift;
 }
 
-static __always_inline u64 __timekeeping_get_ns(const struct tk_read_base *tkr)
+static __always_inline u64 timekeeping_get_ns(const struct tk_read_base *tkr)
 {
 	return timekeeping_cycles_to_ns(tkr, tk_clock_read(tkr));
 }
 
-static inline u64 timekeeping_get_ns(const struct tk_read_base *tkr)
-{
-	if (IS_ENABLED(CONFIG_DEBUG_TIMEKEEPING))
-		return timekeeping_debug_get_ns(tkr);
-
-	return __timekeeping_get_ns(tkr);
-}
-
 /**
  * update_fast_timekeeper - Update the fast and NMI safe monotonic timekeeper.
  * @tkr: Timekeeping readout base from which we take the update
@@ -446,7 +347,7 @@ static __always_inline u64 __ktime_get_fast_ns(struct tk_fast *tkf)
 		seq = raw_read_seqcount_latch(&tkf->seq);
 		tkr = tkf->base + (seq & 0x01);
 		now = ktime_to_ns(tkr->base);
-		now += __timekeeping_get_ns(tkr);
+		now += timekeeping_get_ns(tkr);
 	} while (raw_read_seqcount_latch_retry(&tkf->seq, seq));
 
 	return now;
@@ -562,7 +463,7 @@ static __always_inline u64 __ktime_get_real_fast(struct tk_fast *tkf, u64 *mono)
 		tkr = tkf->base + (seq & 0x01);
 		basem = ktime_to_ns(tkr->base);
 		baser = ktime_to_ns(tkr->base_real);
-		delta = __timekeeping_get_ns(tkr);
+		delta = timekeeping_get_ns(tkr);
 	} while (raw_read_seqcount_latch_retry(&tkf->seq, seq));
 
 	if (mono)
@@ -2300,9 +2201,6 @@ static bool timekeeping_advance(enum timekeeping_adv_mode mode)
 	if (offset < real_tk->cycle_interval && mode == TK_ADV_TICK)
 		goto out;
 
-	/* Do some additional sanity checking */
-	timekeeping_check_update(tk, offset);
-
 	/*
 	 * With NO_HZ we may have to accumulate many cycle_intervals
 	 * (think "ticks") worth of time at once. To do this efficiently,
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 7312ae7c3cc5..3f9c238bb58e 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -1328,19 +1328,6 @@ config SCHEDSTATS
 
 endmenu
 
-config DEBUG_TIMEKEEPING
-	bool "Enable extra timekeeping sanity checking"
-	help
-	  This option will enable additional timekeeping sanity checks
-	  which may be helpful when diagnosing issues where timekeeping
-	  problems are suspected.
-
-	  This may include checks in the timekeeping hotpaths, so this
-	  option may have a (very small) performance impact to some
-	  workloads.
-
-	  If unsure, say N.
-
 config DEBUG_PREEMPT
 	bool "Debug preemptible kernel"
 	depends on DEBUG_KERNEL && PREEMPTION && TRACE_IRQFLAGS_SUPPORT
diff --git a/tools/testing/selftests/wireguard/qemu/debug.config b/tools/testing/selftests/wireguard/qemu/debug.config
index 9d172210e2c6..139fd9aa8b12 100644
--- a/tools/testing/selftests/wireguard/qemu/debug.config
+++ b/tools/testing/selftests/wireguard/qemu/debug.config
@@ -31,7 +31,6 @@ CONFIG_SCHED_DEBUG=y
 CONFIG_SCHED_INFO=y
 CONFIG_SCHEDSTATS=y
 CONFIG_SCHED_STACK_END_CHECK=y
-CONFIG_DEBUG_TIMEKEEPING=y
 CONFIG_DEBUG_PREEMPT=y
 CONFIG_DEBUG_RT_MUTEXES=y
 CONFIG_DEBUG_SPINLOCK=y

Re: FAILED: patch "[PATCH] clocksource: Make negative motion detection more robust" failed to apply to 6.12-stable tree

[Sasha Levin]

[ Sasha's backport helper bot ]

Hi,

Found matching upstream commit: c25ca0c2e42c77e0241411d374d44c41e253b3f5

WARNING: Author mismatch between patch and found commit:
Backport author: Thomas Gleixner <tglx@linutronix.de>
Commit author: Linus Torvalds <torvalds@linux-foundation.org>


Status in newer kernel trees:
6.12.y | Not found

Note: The patch differs from the upstream commit:
---
1:  76031d9536a07 < -:  ------------- clocksource: Make negative motion detection more robust
-:  ------------- > 1:  58afb84e26cfa FAILED: patch "[PATCH] clocksource: Make negative motion detection more robust" failed to apply to 6.12-stable tree
---

Results of testing on various branches:

| Branch                    | Patch Apply | Build Test |
|---------------------------|-------------|------------|
| stable/linux-6.12.y       |  Success    |  Success   |

Re: FAILED: patch "[PATCH] clocksource: Make negative motion detection more robust" failed to apply to 6.12-stable tree

[Greg KH]

On Thu, Dec 12, 2024 at 04:02:06PM +0100, Thomas Gleixner wrote:
> On Thu, Dec 12 2024 at 15:37, Greg KH wrote:
> > On Thu, Dec 12, 2024 at 03:35:14PM +0100, Greg KH wrote:
> >> On Thu, Dec 12, 2024 at 03:32:24PM +0100, Thomas Gleixner wrote:
> >> > On Thu, Dec 12 2024 at 15:18, Greg KH wrote:
> >> > > On Thu, Dec 12, 2024 at 03:17:03PM +0100, Greg KH wrote:
> >> > >> > But I don't think these two commits are necessarily stable material,
> >> > >> > though I don't have a strong opinion on it. If c163e40af9b2 is
> >> > >> > backported, then it has it's own large dependency chain on pre 6.10
> >> > >> > kernels...
> >> > >> 
> >> > >> It's in the queues for some reason, let me figure out why...
> >> > >
> >> > > Ah, it was an AUTOSEL thing, I'll go drop it from all queues except
> >> > > 6.12.y for now, thanks.
> >> > >
> >> > > But, for 6.12.y, we want this fixup too, right?
> >> > 
> >> > If you have c163e40af9b2 pulled back into 6.12.y, then yes. I don't know
> >> > why this actually rejects. I just did
> >> > 
> >> > git-cherry-pick c163e40af9b2
> >> > git-cherry-pick 51f109e92935
> >> > 
> >> > on top of v6.12.4 and that just worked fine.
> >> 
> >> The build breaks :(
> >
> > To be specific:
> >
> > kernel/time/timekeeping.c: In function ‘timekeeping_debug_get_ns’:
> > kernel/time/timekeeping.c:263:17: error: too few arguments to function ‘clocksource_delta’
> >   263 |         delta = clocksource_delta(now, last, mask);
> >       |                 ^~~~~~~~~~~~~~~~~
> > In file included from kernel/time/timekeeping.c:30:
> 
> Ah. You also need:
> 
> d44d26987bb3 ("timekeeping: Remove CONFIG_DEBUG_TIMEKEEPING")
> 
> which in turn does not apply cleanly and needs the backport
> below. *shrug*

Wonderful, thanks for this, that worked I'll go push out a -rc2 with
this soon.

greg k-h