From: Alexandre Belloni <alexandre.belloni@bootlin.com>
To: Jinjie Ruan <ruanjinjie@huawei.com>
Cc: linux-rtc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] rtc: interface: Add rtc time jump debug in rtc_timer_do_work()
Date: Mon, 15 Jun 2026 17:22:31 +0200 [thread overview]
Message-ID: <2026061515223171f111f5@mail.local> (raw)
In-Reply-To: <20260525130825.954214-1-ruanjinjie@huawei.com>
Hello,
On 25/05/2026 21:08:25+0800, Jinjie Ruan wrote:
> In virtualization environments like QEMU [1], or during hardware
> clocksource anomalies, an extreme time-warp event can occur. When
> the system time abruptly jumps forward, the rtc_timer_do_work() handler
> falls into a prolonged processing loop to clear accumulated historical
> timers via timerqueue_getnext(). Running this loop indefinitely under
> the rtc->ops_lock mutex triggers a kernel softlockup, stalling
> the system.
>
> Introduce an adaptive telemetry and loop guard mechanism to enhance debug
> visibility and prevent softlockups:
>
> 1. Record `start_jiffies` upon entry and leverage `time_after()` to
> check if the loop has monopolized the CPU for more than 1s (HZ). If so,
> the handler prints a telemetry warning, triggers a WARN stack dump, and
> breaks the loop to safely yield the CPU.
>
> 2. Track the execution via a `loop_count` metric. Printing this counter
> in the warning log provides vital diagnostics to distinguish
> an aggressive time-warp storm (high count) from a bogged-down callback
> bug (low count).
>
> 3. Utilize the kernel format specifier `%ptR` to convert the raw ktime
> into a human-readable timestamp (YYYY-MM-DD HH:MM:SS), allowing
> developers to instantly pinpoint the exact boundary of the time
> jump in dmesg.
>
> This non-destructive telemetry guard provides precise hardware/emulator
> diagnostic visibility while ensuring core kernel availability.
>
> [1]: https://lore.kernel.org/all/20260114013257.3500578-1-ruanjinjie@huawei.com/
> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
> ---
> drivers/rtc/interface.c | 15 +++++++++++++--
> 1 file changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/rtc/interface.c b/drivers/rtc/interface.c
> index 1906f4884a83..f6c5fd16cc4e 100644
> --- a/drivers/rtc/interface.c
> +++ b/drivers/rtc/interface.c
> @@ -927,10 +927,12 @@ static void rtc_timer_remove(struct rtc_device *rtc, struct rtc_timer *timer)
> */
> void rtc_timer_do_work(struct work_struct *work)
> {
> - struct rtc_timer *timer;
> + unsigned long start_jiffies = jiffies;
> struct timerqueue_node *next;
> - ktime_t now;
> + struct rtc_timer *timer;
> struct rtc_time tm;
> + int loop_count = 0;
> + ktime_t now;
> int err;
>
> struct rtc_device *rtc =
> @@ -945,6 +947,15 @@ void rtc_timer_do_work(struct work_struct *work)
> }
> now = rtc_tm_to_ktime(tm);
> while ((next = timerqueue_getnext(&rtc->timerqueue))) {
> + loop_count++;
> +
> + if (unlikely(time_after(jiffies, start_jiffies + HZ))) {
> + dev_warn(&rtc->dev, "RTC time jump (loop: %d) to %ptR.\n",
> + loop_count, &tm);
> + WARN_ON_ONCE(1);
So, your issue is that it is too slow so you make it even slower? There
are already plenty of tracepoints that allow proper debugging in this
loop, I'm pretty sure we don't want to bloat the kernel with more
messages.
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
prev parent reply other threads:[~2026-06-15 15:22 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-25 13:08 [PATCH] rtc: interface: Add rtc time jump debug in rtc_timer_do_work() Jinjie Ruan
2026-06-11 1:40 ` Jinjie Ruan
2026-06-11 2:01 ` Jinjie Ruan
2026-06-15 15:22 ` Alexandre Belloni [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2026061515223171f111f5@mail.local \
--to=alexandre.belloni@bootlin.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rtc@vger.kernel.org \
--cc=ruanjinjie@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox