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.ne...
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. */
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
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...
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
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
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 :(
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:
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
[ 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 |
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
linux-stable-mirror@lists.linaro.org