timers: description
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest5 patches 0 repliesNew
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/5 | timers: prepare for del_timer_sync() changesinclude/ kernel/ | +34 | 0 replies | |
| 2/5 | timers: rework del_timer_sync()include/ kernel/ | +60 | 0 replies | |
| 3/5 | timers: serialize timerskernel/ | +10 | 0 replies | |
| 4/5 | timers: remove memory barrierskernel/ | +0 | 0 replies | |
| 5/5 | timers: cleanup, kill __get_base()kernel/ | +7 | 0 replies |
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [PATCH 0/5] timers: description
Hello.
These patches are updated version of 'del_timer_sync: proof of concept' 2 patches.
1/5:
unchanded.
2/5:
del_timer_sync() simplified. It is not neccessary to unlock and retry if __TIMER_PENDING has changed, it is only neccessary if timer's base == (timer->_base & ~1) has changed. Also, comments are updated.
3/5:
The reworked del_timer_sync() can't work unless timers are serialized wrt to itself. They are not.
I missed the fact that __mod_timer() can change timer's base while the timer is running.
4/5:
remove memory barrier in __run_timers() and del_timer().
5/5:
kill ugly __get_base(), it was temporal.
The del_singleshot_timer_sync function now unneeded, but it looks like additional test for del_timer_sync(), so it will be removed later.
Btw, add_timer_on() is racy against __mod_timer(), is it worth fixing?
Oleg.