Re: [PATCH v2] rust: hrtimer: Restrict expires() to safe contexts

["Gary Guo" <gary@garyguo.net>]

On Thu Feb 26, 2026 at 6:33 PM GMT, Andreas Hindborg wrote:
> "Gary Guo" <gary@garyguo.net> writes:
>
>> On Thu Feb 26, 2026 at 1:19 PM GMT, Andreas Hindborg wrote:
>>> FUJITA Tomonori <tomo@aliasing.net> writes:
>>>
>>>> On Thu, 26 Feb 2026 11:42:39 +0000
>>>> "Gary Guo" <gary@garyguo.net> wrote:
>>>>
>>>> >> diff --git a/rust/kernel/time/hrtimer.rs b/rust/kernel/time/hrtimer.rs
>>>> >> index 856d2d929a00..78e2343fd016 100644
>>>> >> --- a/rust/kernel/time/hrtimer.rs
>>>> >> +++ b/rust/kernel/time/hrtimer.rs
>>>> >> @@ -224,27 +224,39 @@ pub fn forward_now(self: Pin<&mut Self>, interval: Delta) -> u64
>>>> >>          self.forward(HrTimerInstant::<T>::now(), interval)
>>>> >>      }
>>>> >>
>>>> >> +    /// Return the time expiry for this [`HrTimer`].
>>>> >> +    ///
>>>> >> +    /// # Safety
>>>> >> +    ///
>>>> >> +    /// - `self_ptr` must point to a valid `Self`.
>>>> >> +    /// - The caller must either have exclusive access to the data pointed to by `self_ptr`, or be
>>>> >> +    ///   within the context of the timer callback.
>>>> >> +    #[inline]
>>>> >> +    unsafe fn raw_expires(self_ptr: *const Self) -> HrTimerInstant<T>
>>>> >
>>>> > I guess the signature of this can also be
>>>> >
>>>> > `unsafe fn raw_expires(&self) -> HrTimerInstant<T>`? Then you can remove the
>>>> > first safety requirement.
>>>>
>>>> Thanks, I've updated the signature to use &self.
>>>>
>>>> Andreas, this breaks the consistency with raw_forward. Is this
>>>> acceptable?
>>>
>>> If we do this, we get to argue that the NonNull we have in the callback context
>>> is convertible to a reference. Either way is fine with me.
>>>
>>> If you change this to a reference, then I think we should rename the function to
>>> `expires_unchecked`. The `raw` usually refers to operations on pointers rather
>>> than references.
>>
>> Does it make sense to simply have `HrTimerCallback<'a, T: ...>(&'a HrTimer<T>)`?
>
> I assume you mean `HrTimerCallbackContext`.
>
> Could it be a mut reference? We are supposed to have exclusive access
> when we have the context.

If `Pin<&mut Hrtimer>` would work, then we can perhaps remove the
`HrTimerCallbackContext` type and just pass a `Pin<&mut HrTimer>` to the callback?

Best,
Gary

>
>
> Best regards,
> Andreas Hindborg