Re: [PATCH v3] rust: hrtimer: add active() method to query timer state

[FUJITA Tomonori <tomo@flapping.org>]

On Thu, 05 Nov 2026 11:17:24 +0100
Andreas Hindborg <a.hindborg@kernel.org> wrote:

> Add an `active()` method to HrTimer that returns true if the timer is in
> the started or running states. This wraps the kernel's hrtimer_active()
> function.
> 
> Unlike a direct read of `node.expires`, this does not race with a
> concurrent start operation. hrtimer_active() reads the timer state inside a
> seqcount retry loop and re-reads `timer->base` with READ_ONCE(), and the
> core documents that it must not return a false negative. No exclusive
> access to the timer is therefore required, and the SAFETY comment reflects
> that.
> 
> The returned value is still only a snapshot: a concurrent start or an
> expiry can change the state right after the call. Callers that need a
> stable answer have to serialize against those operations themselves,
> exactly as C callers of hrtimer_active() do. This is documented on the
> method.
> 
> Also add documentation clarifying the definition of an active timer.
> 
> Introduce the term `active` as a set of timer states composed of `started`
> and `running`.
> 
> Reviewed-by: FUJITA Tomonori <fujita.tomonori@gmail.com>
> Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>

[...]

> +    /// Query the state of the timer.
> +    ///
> +    /// Returns [`true`] if the timer is in the started or running states.
> +    ///
> +    /// This method synchronizes internally and does not require exclusive access to the timer.
> +    ///
> +    /// The returned value is a snapshot. A concurrent start or expiry can change the state of the
> +    /// timer right after this method returns, so callers that need the state to be stable must
> +    /// serialize against those operations by other means.

Does "expiry" here mean that the callback returns HrTimerRestart::NoRestart
on another CPU? An expiry alone moves the timer from started to running, so
active() still returns true. If so, I think it is clearer to write this case
directly, and to add the case where the timer is canceled on another CPU.

The same sentence is in the commit message, so please update it too.