[PATCH] hrtimer: Fix missing debug object calls in in-place update path

[PATCH] hrtimer: Fix missing debug object calls in in-place update path

[suryasaimadhu]

From: suryasaimadhu <suryasaimadhu369@gmail.com>

Commit 343f2f4dc542 ("hrtimer: Try to modify timers in place")
introduced an optimization that updates the timer expiry in-place
without dequeuing and re-enqueuing it when the new expiry falls
within the range of neighbouring timers.

However, the in-place path skips debug_hrtimer_deactivate() and
debug_hrtimer_activate() calls, leaving the ODEBUG state machine
out of sync. When ODEBUG subsequently sees the timer in an
unexpected state, hrtimer_fixup_assert_init() fires and installs
stub_timer() as the callback. When the timer then expires,
stub_timer() hits WARN_ON(1) causing a kernel panic.

Fix this by adding the missing debug object deactivate/activate
calls in the in-place update path.

Reported-by: syzbot+5e8dda76ca21dae314b6@syzkaller.appspotmail.com
Fixes: 343f2f4dc542 ("hrtimer: Try to modify timers in place")
Signed-off-by: suryasaimadhu <SaiMadhu.KoyyalaHariVenkata@amd.com>
---
 kernel/time/hrtimer.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c
index 638ce623c342..f60f109a299a 100644
--- a/kernel/time/hrtimer.c
+++ b/kernel/time/hrtimer.c
@@ -1243,6 +1243,8 @@ remove_and_enqueue_same_base(struct hrtimer *timer, struct hrtimer_clock_base *b
 		/* Try to update in place to avoid the de/enqueue dance */
 		if (hrtimer_can_update_in_place(timer, base, expires)) {
 			hrtimer_set_expires_range_ns(timer, expires, delta_ns);
+			debug_hrtimer_deactivate(timer);
+			debug_hrtimer_activate(timer, mode);
 			trace_hrtimer_start(timer, mode, true);
 			if (was_first)
 				base->expires_next = expires;
-- 
2.47.3

[PATCH] hrtimer: Fix missing debug object calls in in-place update path

[suryasaimadhu]

From: Surya Sai Madhu <suryasaimadhu369@gmail.com>

Commit 343f2f4dc542 ("hrtimer: Try to modify timers in place")
introduced an optimization that updates the timer expiry in-place
without dequeuing and re-enqueuing it when the new expiry falls
within the range of neighbouring timers.

However, the in-place path skips debug_hrtimer_deactivate() and
debug_hrtimer_activate() calls, leaving the ODEBUG state machine
out of sync. When ODEBUG subsequently sees the timer in an
unexpected state, hrtimer_fixup_assert_init() fires and installs
stub_timer() as the callback. When the timer then expires,
stub_timer() hits WARN_ON(1) causing a kernel panic.

Fix this by adding the missing debug object deactivate/activate
calls in the in-place update path.

Reported-by: syzbot+5e8dda76ca21dae314b6@syzkaller.appspotmail.com
Fixes: 343f2f4dc542 ("hrtimer: Try to modify timers in place")
Signed-off-by: suryasaimadhu <SaiMadhu.KoyyalaHariVenkata@amd.com>
---
 kernel/time/hrtimer.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c
index 638ce623c342..f60f109a299a 100644
--- a/kernel/time/hrtimer.c
+++ b/kernel/time/hrtimer.c
@@ -1243,6 +1243,8 @@ remove_and_enqueue_same_base(struct hrtimer *timer, struct hrtimer_clock_base *b
 		/* Try to update in place to avoid the de/enqueue dance */
 		if (hrtimer_can_update_in_place(timer, base, expires)) {
 			hrtimer_set_expires_range_ns(timer, expires, delta_ns);
+			debug_hrtimer_deactivate(timer);
+			debug_hrtimer_activate(timer, mode);
 			trace_hrtimer_start(timer, mode, true);
 			if (was_first)
 				base->expires_next = expires;
-- 
2.47.3

[PATCH] hrtimer: Fix missing debug object calls in in-place update path

[suryasaimadhu]

From: Surya Sai Madhu <suryasaimadhu369@gmail.com>

Commit 343f2f4dc542 ("hrtimer: Try to modify timers in place")
introduced an optimization that updates the timer expiry in-place
without dequeuing and re-enqueuing it when the new expiry falls
within the range of neighbouring timers.

However, the in-place path skips debug_hrtimer_deactivate() and
debug_hrtimer_activate() calls, leaving the ODEBUG state machine
out of sync. When ODEBUG subsequently sees the timer in an
unexpected state, hrtimer_fixup_assert_init() fires and installs
stub_timer() as the callback. When the timer then expires,
stub_timer() hits WARN_ON(1) causing a kernel panic.

Fix this by adding the missing debug object deactivate/activate
calls in the in-place update path.

Reported-by: syzbot+5e8dda76ca21dae314b6@syzkaller.appspotmail.com
Fixes: 343f2f4dc542 ("hrtimer: Try to modify timers in place")
Signed-off-by: suryasaimadhu <SaiMadhu.KoyyalaHariVenkata@amd.com>
---
 kernel/time/hrtimer.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c
index 638ce623c342..f60f109a299a 100644
--- a/kernel/time/hrtimer.c
+++ b/kernel/time/hrtimer.c
@@ -1243,6 +1243,8 @@ remove_and_enqueue_same_base(struct hrtimer *timer, struct hrtimer_clock_base *b
 		/* Try to update in place to avoid the de/enqueue dance */
 		if (hrtimer_can_update_in_place(timer, base, expires)) {
 			hrtimer_set_expires_range_ns(timer, expires, delta_ns);
+			debug_hrtimer_deactivate(timer);
+			debug_hrtimer_activate(timer, mode);
 			trace_hrtimer_start(timer, mode, true);
 			if (was_first)
 				base->expires_next = expires;
-- 
2.47.3

[PATCH] hrtimer: Fix missing debug object calls in in-place update path

[suryasaimadhu]

From: Surya Sai Madhu <suryasaimadhu369@gmail.com>

Commit 343f2f4dc542 ("hrtimer: Try to modify timers in place")
introduced an optimization that updates the timer expiry in-place
without dequeuing and re-enqueuing it when the new expiry falls
within the range of neighbouring timers.

However, the in-place path skips debug_hrtimer_deactivate() and
debug_hrtimer_activate() calls, leaving the ODEBUG state machine
out of sync. When ODEBUG subsequently sees the timer in an
unexpected state, hrtimer_fixup_assert_init() fires and installs
stub_timer() as the callback. When the timer then expires,
stub_timer() hits WARN_ON(1) causing a kernel panic.

Fix this by adding the missing debug object deactivate/activate
calls in the in-place update path.

Reported-by: syzbot+5e8dda76ca21dae314b6@syzkaller.appspotmail.com
Fixes: 343f2f4dc542 ("hrtimer: Try to modify timers in place")
Signed-off-by: suryasaimadhu <suryasaimadhu369@gmail.com>
---
Note: Please consider this submission. Previous sends had email
configuration issues and were sent from the wrong address.

 kernel/time/hrtimer.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c
index 638ce623c342..f60f109a299a 100644
--- a/kernel/time/hrtimer.c
+++ b/kernel/time/hrtimer.c
@@ -1243,6 +1243,8 @@ remove_and_enqueue_same_base(struct hrtimer *timer, struct hrtimer_clock_base *b
 		/* Try to update in place to avoid the de/enqueue dance */
 		if (hrtimer_can_update_in_place(timer, base, expires)) {
 			hrtimer_set_expires_range_ns(timer, expires, delta_ns);
+			debug_hrtimer_deactivate(timer);
+			debug_hrtimer_activate(timer, mode);
 			trace_hrtimer_start(timer, mode, true);
 			if (was_first)
 				base->expires_next = expires;
-- 
2.47.3

[PATCH] hrtimer: Fix missing debug object calls in in-place update path

[Surya Sai Madhu]

Commit 343f2f4dc542 ("hrtimer: Try to modify timers in place")
introduced an optimization that updates the timer expiry in-place
without dequeuing and re-enqueuing it when the new expiry falls
within the range of neighbouring timers.

However, the in-place path skips debug_hrtimer_deactivate() and
debug_hrtimer_activate() calls, leaving the ODEBUG state machine
out of sync. When ODEBUG subsequently sees the timer in an
unexpected state, hrtimer_fixup_assert_init() fires and installs
stub_timer() as the callback. When the timer then expires,
stub_timer() hits WARN_ON(1) causing a kernel panic.

Fix this by adding the missing debug object deactivate/activate
calls in the in-place update path.

Reported-by: syzbot+5e8dda76ca21dae314b6@syzkaller.appspotmail.com
Fixes: 343f2f4dc542 ("hrtimer: Try to modify timers in place")
Signed-off-by: suryasaimadhu <suryasaimadhu369@gmail.com>
---
Note: Please consider this submission. Previous sends had email
configuration issues and were sent from the wrong address.

 kernel/time/hrtimer.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c
index 638ce623c342..f60f109a299a 100644
--- a/kernel/time/hrtimer.c
+++ b/kernel/time/hrtimer.c
@@ -1243,6 +1243,8 @@ remove_and_enqueue_same_base(struct hrtimer *timer, struct hrtimer_clock_base *b
 		/* Try to update in place to avoid the de/enqueue dance */
 		if (hrtimer_can_update_in_place(timer, base, expires)) {
 			hrtimer_set_expires_range_ns(timer, expires, delta_ns);
+			debug_hrtimer_deactivate(timer);
+			debug_hrtimer_activate(timer, mode);
 			trace_hrtimer_start(timer, mode, true);
 			if (was_first)
 				base->expires_next = expires;
-- 
2.47.3

Re: [PATCH] hrtimer: Fix missing debug object calls in in-place update path

[Thomas Gleixner]

On Fri, Jun 19 2026 at 21:13, Surya Sai Madhu wrote:
> Commit 343f2f4dc542 ("hrtimer: Try to modify timers in place")
> introduced an optimization that updates the timer expiry in-place
> without dequeuing and re-enqueuing it when the new expiry falls
> within the range of neighbouring timers.
>
> However, the in-place path skips debug_hrtimer_deactivate() and
> debug_hrtimer_activate() calls, leaving the ODEBUG state machine
> out of sync. When ODEBUG subsequently sees the timer in an
> unexpected state, hrtimer_fixup_assert_init() fires and installs
> stub_timer() as the callback. When the timer then expires,
> stub_timer() hits WARN_ON(1) causing a kernel panic.

The debugobjects state of the timer is ACTIVE, otherwise it would not be
enqueued. hrtimer_fixup_assert_init() does not fire subsequently at
all. It is invoked on the first attempt to activate the non-initialized
timer and that is _before_ the timer was started the first time. See
hrtimer_start_range_ns() and hrtimer_start_range_ns_user().

So no, there is nothing out of sync and nothing to fix here. Your patch
is just a pointless exercise switching the debug objects state from
ACTIVE to INACTIVE and back to ACTIVE.

The real problem is somewhere else and has nothing to do with modify in
place.

Unfortunately the WARN() which is emitted by the debugobjects fixup
function, which also installs the stub_timer callback via
hrtimer_fixup_assert_init(), is not in the console log. That's puzzling.

Thanks,

        tglx