sys/xtimer: Avoid race incrementing multiple periods in _timer_callback#3998
Conversation
On a fast CPU with a slow timer (e.g. XTIMER_SHIFT > 0) it is possible that now == _xtimer_now() when spinning for the overflow. In the extreme case When this happens _next_period() will be called more than once until the timer overflows for real. Fault observed in real life when running on a 32.768 kHz timer on a ~96 MHz clocked mulle (Kinetis K60, Cortex-M4). _next_period() was called 9 times during the same ISR call before the 32 kHz timer overflowed.
jnohlgard
added
Type: bug
|
The severity of this bug varies greatly depending on how well the XTIMER_BACKOFF value is tuned to the actual required backoff. A greater XTIMER_BACKOFF value will make the effects more severe (more invocations of _next_period). |
|
ACK. We're ironing out more and more potential time-travels, great! |
|
There needs to be a PR to the release branch too for this, right? |
|
@authmillenon this is kind of a corner case in the current implementation which won't happen on the current platforms until we start using slower timers, e.g. via #3990 |
|
@authmillenon I opened #4000 for the same fix for the release |
sys/xtimer: Avoid race incrementing multiple periods in _timer_callback
|
Don't you love when a whole-evening bug hunting session results in a patch which changes a single character in the source code? |
|
Off-by-one errors are the best :-) |
3 participants
On a fast CPU with a slow timer (e.g. XTIMER_SHIFT > 0) it is possible
that now == _xtimer_now() when spinning for the overflow. In the extreme
case When this happens _next_period() will be called more than once
until the timer overflows for real.
Fault observed in real life when running on a 32.768 kHz timer on a
~96 MHz clocked mulle (Kinetis K60, Cortex-M4). _next_period() was
called 9 times during the same ISR call before the 32 kHz timer
overflowed.