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.
Detailed description
This PR addresses an issue in the platform timeouts subsystem where the firmware will execute and handle timeouts very wrongly for a few seconds after ~49.7 days of uptime.
The gist of the bug is that as the time_ms counter approaches UINT32_MAX and platform_timeout_set() starts generating expiration times close to 0, the comparison for whether the timeout has expired will incorrectly determine that it has at the start of the timeout validity interval. This is incredibly wrong and will cause all manner of broken behaviour in anything that depends on timeouts to function properly.
We fix this by detecting this edge condition where the uptime counter has the MSb set and the expiration time does not and force the comparison to false. This is wrong if a timeout is requested that is exceedingly large (~231ms) but as the firmware never does that and that would be a ~25.8 day timeout, this edge-case is irrelevant.
Your checklist for this pull request
Closing issues