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

On Mon, 24 Aug 2026 12:44:44 +0200
Andreas Hindborg <[email protected]> wrote:

> FUJITA Tomonori <[email protected]> writes:
> 
>> On Fri, 21 Aug 2026 09:13:01 +0200
>> Andreas Hindborg <[email protected]> wrote:
>>
>>> 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.
>>
>> Could you propose the solution to the C maintainers? I will do the
>> Rust side, whichever way it goes.
> 
> Not sure what you are asking. C people are CC in this thread. I think
> the best way to discuss is to write a patch that can be the basis of
> discussion. Do you want me to draft up something, or do you want to do
> that?

The former, please.

This thread has a lot of Rust-specific detail, so I think a new thread
with the patch would be a better basis for the discussion.