[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <176907693616.510.2787077916492064360.tip-bot2@tip-bot2>
Date: Thu, 22 Jan 2026 10:15:36 -0000
From: "tip-bot2 for Thomas Gleixner" <tip-bot2@...utronix.de>
To: linux-tip-commits@...r.kernel.org
Cc: "Peter Zijlstra (Intel)" <peterz@...radead.org>,
Thomas Gleixner <tglx@...utronix.de>, x86@...nel.org,
linux-kernel@...r.kernel.org
Subject: [tip: sched/core] hrtimer: Fix trace oddity
The following commit has been merged into the sched/core branch of tip:
Commit-ID: 5d6446f409da00e5a389125ddb5ce09f5bc404c9
Gitweb: https://git.kernel.org/tip/5d6446f409da00e5a389125ddb5ce09f5bc404c9
Author: Thomas Gleixner <tglx@...utronix.de>
AuthorDate: Mon, 19 Jan 2026 11:38:34 +01:00
Committer: Peter Zijlstra <peterz@...radead.org>
CommitterDate: Thu, 22 Jan 2026 11:11:20 +01:00
hrtimer: Fix trace oddity
It turns out that __run_hrtimer() will trace like:
<idle>-0 [032] d.h2. 20705.474563: hrtimer_cancel: hrtimer=0xff2db8f77f8226e8
<idle>-0 [032] d.h1. 20705.474563: hrtimer_expire_entry: hrtimer=0xff2db8f77f8226e8 now=20699452001850 function=tick_nohz_handler/0x0
Which is a bit nonsensical, the timer doesn't get canceled on
expiration. The cause is the use of the incorrect debug helper.
Fixes: c6a2a1770245 ("hrtimer: Add tracepoint for hrtimers")
Reported-by: Peter Zijlstra (Intel) <peterz@...radead.org>
Signed-off-by: Thomas Gleixner <tglx@...utronix.de>
Signed-off-by: Peter Zijlstra (Intel) <peterz@...radead.org>
Link: https://patch.msgid.link/20260121143208.219595606@infradead.org
---
kernel/time/hrtimer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c
index f8ea8c8..d8935ab 100644
--- a/kernel/time/hrtimer.c
+++ b/kernel/time/hrtimer.c
@@ -1742,7 +1742,7 @@ static void __run_hrtimer(struct hrtimer_cpu_base *cpu_base,
lockdep_assert_held(&cpu_base->lock);
- debug_deactivate(timer);
+ debug_hrtimer_deactivate(timer);
base->running = timer;
/*
Powered by blists - more mailing lists