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

[Thomas Gleixner <tglx@linutronix.de>]

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