Re: [PATCH 0/4] Fix forward()/expires() racing with concurrent arming
FUJITA Tomonori <[email protected]>
| Newsgroups | org.kernel.vger.rust-for-linux |
|---|---|
| Message-ID | <[email protected]> |
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.