Re: [PATCH 0/4] Fix forward()/expires() racing with concurrent arming

FUJITA Tomonori <[email protected]> writes:

> On Thu, 20 Aug 2026 14:34:16 +0200
> Andreas Hindborg <[email protected]> wrote:
>
>>>> We discussed this at the call last night. We came to the conclusion that
>>>> we would like to experiment with the solution outlined by Gary, where we
>>>> inject `expires` into the callback handler, and the callback handler
>>>> returns a forward duration in addition to a restart value. Because with
>>>> that approach, we can avoid adding complexity to the Arc end of the API.
>>>> 
>>>> For the best implementation of this scheme, we probably need to change
>>>> some bits in the C code, add an additional path. Down the line, we could
>>>> also see how man callers of the C code can be changed to use this
>>>> pattern.
>>>> 
>>>> Do you want to send a patch based on this solution Tomo?
>>>
>>> https://lore.kernel.org/rust-for-linux/[email protected]/
>>>
>>> The solution that we discussed before, right? It changes how the
>>> hrtimer core calls the callback. If the C maintainers take that, I
>>> will do the Rust side for it.
>> 
>> Yes this one. We don't know if C maintainers will like it. We were
>> discussing having a separate path on the C side just for just,
>> alternatively converting C side callers.
>> 
>> I think we should be able to reach some kind of agreement with C
>> timekeeping. But if not, we can solve it on rust side only, but less
>> efficient. We can grab the base lock again, read expires, then drop the
>> lock. But better to do it in the C code.
>
> The Rust side cannot take the base lock: lock_hrtimer_base() is static
> in kernel/time/hrtimer.c, internal to the core. So that way needs some
> agreement with the C maintainers as well.

Right, we would have to export the symbol, or a function for this
purpose. But it is a smaller change to C code. I would prefer we solve
it properly though, not with hacks.


Best regards,
Andreas Hindborg

r