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

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

On Tue Mar 10, 2026 at 8:24 AM GMT, Andreas Hindborg wrote:
> "Gary Guo" <gary@garyguo.net> writes:
>
>> On Sat Feb 28, 2026 at 1:26 AM GMT, FUJITA Tomonori wrote:
>>> On Fri, 27 Feb 2026 12:32:05 +0000
>>> "Gary Guo" <gary@garyguo.net> wrote:
>>>
>>>> On Thu Feb 26, 2026 at 6:33 PM GMT, Andreas Hindborg wrote:
>>>>> "Gary Guo" <gary@garyguo.net> writes:
>>>>>
>>>>>> 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?
>>>
>>> During the callback, ArcTimerHandle still holds Arc<T>, and the
>>> callback receives ArcBorrow<T>. Creating Pin<&mut HrTimer<T>> would
>>> cause aliasing between &HrTimer<T> and &mut HrTimer<T>?
>>
>> This is fine from an aliasing POV as `Opaque` cancels the noalias requirement
>> of `&mut` already.
>>
>> As long as we can guarantee that no method on `Pin<&mut HrTimer<T>>` can race
>> with methods on `&HrTimer<T>` it should be okay.
>
> Is this really OK?
>
> struct Foo {
>   timer: HrTimer<Foo>,
> }
>
> Surely it cannot be OK to hold both `&Foo` and `Pin<&mut HrTimer<Foo>>`,
> even though the internals of `HrTimer<_>` is an `Opaque` field?

It's not UB to hold both, otherwise you cannot write intrusive data structures.

It might be useful to think the mutable reference that the hrtime callback
receives is th same as getting a reference to mutex content, while others can
still reference the mutex.

We can probably have two types, where one can have shared refs (for starting the
timer) and the other is exclusive only?

Best,
Gary