On Thu, Oct 01 2026 at 00:29, Gary Guo wrote:
> On Wed Sep 30, 2026 at 10:43 PM BST, Thomas Gleixner wrote:
>> So what's your actual argument that you can't build a "safe" Rust API
>> around this?
>
> Sure, if all expiry read/update functions have their _safe_from_callback
> variant.
Why do you need more than the safe forward variant to solve
the problem of preventing that a callback forward and a concurrent start
collide and create inconsistent state?
Just to take a step back. We have two sorts of hrtimer usage:
1) a simple "start, wait or cancel, done" sequence, e.g. nanosleep()
2) a more complex scenario which has to take care of concurrency,
e.g. POSIX interval timers
#1 does not need any of this
#2 has almost always a related data structure, which needs to be kept
consistent by some form of serialization. The embedded hrtimer is
just a small low level detail of the overall use case logic.
The base lock _cannot_ provide the required serialization and any
amount of 'callback safe' addons will not change that.
I completely understand that you want to create a fool proof hrtimer
Rust API, but honestly that's just creating an illusion of correctness.
If the core provides you a get_expiry_safe() variant, which takes the
lock before reading, then what is the return value?
It's a snapshot which might be invalid at the time of usage already.
Ergo, if you need consistent state across concurrent contexts including
the callback, then the only solution for that is external serialization.
I'm not against hardening the core implementation against API misuse
where it makes sense. But that's hardening and cannot solve the other
problems which are solely in the scope of the usage sites.
Thanks,
tglx
