[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260121143208.219595606@infradead.org>
Date: Wed, 21 Jan 2026 15:25:01 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: tglx@...utronix.de,
mathieu.desnoyers@...icios.com
Cc: linux-kernel@...r.kernel.org,
peterz@...radead.org,
paulmck@...nel.org,
boqun.feng@...il.com,
corbet@....net,
prakash.sangappa@...cle.com,
vineethr@...ux.ibm.com,
kprateek.nayak@....com,
rostedt@...dmis.org,
bigeasy@...utronix.de,
arnd@...db.de,
rdunlap@...radead.org,
rongevarg@...il.com,
longman@...hat.com
Subject: [PATCH 4/5] 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>
---
kernel/time/hrtimer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/kernel/time/hrtimer.c
+++ b/kernel/time/hrtimer.c
@@ -1750,7 +1750,7 @@ static void __run_hrtimer(struct hrtimer
lockdep_assert_held(&cpu_base->lock);
- debug_deactivate(timer);
+ debug_hrtimer_deactivate(timer);
base->running = timer;
/*
Powered by blists - more mailing lists