sys/ztimer: fix re-scheduling of timers [backport 2024.07]#20928
Closed
maribu wants to merge 1 commit intoRIOT-OS:2024.07-branchfrom
Closed
sys/ztimer: fix re-scheduling of timers [backport 2024.07]#20928maribu wants to merge 1 commit intoRIOT-OS:2024.07-branchfrom
maribu wants to merge 1 commit intoRIOT-OS:2024.07-branchfrom
Conversation
If the timer at the head of a ztimer clock's timer list is re-scheduled (ztimer_set() called on an already set timer) and the timer is no longer at the head after being re-scheduled, clock-ops->set() is never called from inside ztimer_set(), and the underlying timer is left with an ISR scheduled to expire at the timer's old time. The intended behavior is that the clock's lower level timer should always be set to expire at the time of the clocks head timer. This patch changes ztimer_set() to call _ztimer_update(), which sets the lower level timer according to the current list of timers, rather than setting the timer directly inside of ztimer_set(). (cherry picked from commit 45942f6)
Member
Author
|
This backport will not pass the CI until #20929 is merged. |
Member
Author
|
@Teufelchen1 IMO this bug easily qualifies as backport material. Care to take a look? |
Teufelchen1
approved these changes
Oct 23, 2024
Contributor
Teufelchen1
left a comment
There was a problem hiding this comment.
Not super deep into ztimer tbh but looks reasonable (and matches the off-github discussion)
Member
Author
|
Realisticly: Let's just rather get the new release out soon that will contain the fix. |
auto-merge was automatically disabled
November 12, 2024 15:00
Pull request was closed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Backport of #20924
Contribution description
If the timer at the head of a ztimer clock's timer list is re-scheduled (
ztimer_set()called on an already set timer) and the timer is no longer at the head after being re-scheduled,clock-ops->set()is never called from insideztimer_set(), and the underlying timer is left with an ISR scheduled to expire at the timer's old time. The intended behavior is that the clock's lower level timer should always be set to expire at the time of the clocks head timer.This patch changes
ztimer_set()to call_ztimer_update(), which sets the lower level timer according to the current list of timers, rather than setting the timer directly inside ofztimer_set().This is a fix we might consider back porting. As far as I can tell this bug has always existed in
ztimer.Testing procedure
make -C examples/hello-world/ all termTestbench patch
Sample of testbench's expected (good) behavior
Sample of testbench's behavior without this fix
Issues/PRs references
This bug is possible the cause of the early timeout worked around in this #19965. Perhaps that workaround could be removed?