[PATCH] rust: hrtimer: document handle based design rationale
From: Andreas Hindborg
Date: Sun Feb 15 2026 - 15:36:32 EST
Add implementation notes explaining why the hrtimer abstraction uses a
handle based approach.
Signed-off-by: Andreas Hindborg <a.hindborg@xxxxxxxxxx>
---
rust/kernel/time/hrtimer.rs | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/rust/kernel/time/hrtimer.rs b/rust/kernel/time/hrtimer.rs
index 856d2d929a008..f92880b2cbdbd 100644
--- a/rust/kernel/time/hrtimer.rs
+++ b/rust/kernel/time/hrtimer.rs
@@ -67,6 +67,18 @@
//! A `restart` operation on a timer in the **stopped** state is equivalent to a
//! `start` operation.
+// Implementation details
+//
+// The reasoning for adopting a handle based approach:
+// - If we explicitly drop the target of a timer callback in the timer callback, we
+// may get a dangling reference.
+// - If the callback owns the last reference to the target, target may be dropped
+// in non-sleepable context when the callback is finished.
+// - When dropping an object that is the target of an armed timer, we may drop
+// fields accessed by the timer callback before we cancel the timer (drop order).
+//
+// By using a handle, we can make the handle own the callback target and avoid these problems.
+
use super::{ClockSource, Delta, Instant};
use crate::{prelude::*, types::Opaque};
use core::{marker::PhantomData, ptr::NonNull};
---
base-commit: 05f7e89ab9731565d8a62e3b5d1ec206485eeb0b
change-id: 20260215-hrtimer-docs-52ec9c020285
Best regards,
--
Andreas Hindborg <a.hindborg@xxxxxxxxxx>