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

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?

After we submit the patch, if they do not respond, I can see if I can
find one of them in person at LPC. But I think they usually respond.

Best regards,
Andreas Hindborg