Re: [PATCH v2] hrtimer: Use hard expiry when updating timers on the same base
From: Thomas Gleixner
Date: Wed Sep 09 2026 - 12:59:47 EST
On Wed, Sep 09 2026 at 12:27, Andrea Parri wrote:
> @@ -1263,13 +1263,16 @@ remove_and_enqueue_same_base(struct hrtimer *timer, struct hrtimer_clock_base *b
> {
> bool was_first = false;
>
> + /* Set the new expiry time */
> + hrtimer_set_expires_range_ns(timer, expires, delta_ns);
> + expires = hrtimer_get_expires(timer);
My knee jerk reaction when reading this the first time was something
non-printable because the obvious rule is that you can't change the sort
key of a tree entry when that can make the tree inconsistent.
As the base lock is held and nothing can observe the potentially
resulting inconsistency at that point and the timer either stays in
place or is dequeued, this is safe, but non obvious.
So this really wants to have a big fat comment explaining why this is
safe to do.
Thanks,
tglx