Remove most panics from timer-related operations #1749
Merged
Conversation
This file contains 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
cbiffle
force-pushed
the
cbiffle/no-panic-timestamp-ops
branch
4 times, most recently
from
93caf7c
to
ed8ed3b
Compare
cbiffle
force-pushed
the
cbiffle/no-panic-timestamp-ops
branch
from
ed8ed3b
to
94fb39b
Compare
hawkw
approved these changes
Apr 16, 2024
aapoalas
reviewed
Apr 16, 2024
Merged
Previously sleep_for was panicking if the provided timeout plus the current kernel timestamp overflowed a u64. This inserted a subtle and difficult-to-remove panic site in many programs. This changes it to use saturating arithmetic instead. Saturating arithmetic is still more expensive than wrapping arithmetic (on u64s, at least, our processors have hardware saturating arithmetic but only up to u32), but it is far cheaper than a panic. This means that a program that provides a very, very large timeout will sleep until "the end of time" (the 64-bit timestamp rollover in 584.5 million years) instead of panicking. Given that the overflow constraint wasn't previously documented in the API, and given that our timeout values tend to be small and constant, this seems to me like an acceptable compromise to reduce text size.
Previously a race condition between the RoT IRQ event and the timer event could cause this to detect a timeout immediately on the _next_ time it was called, due to a notification being left pending. This is because the code assumed that the notification for the timer was sufficient to give up on the remote device; that's not actually the case. This changes the code to look at the clock before making decisions about elapsed time.
cbiffle
force-pushed
the
cbiffle/no-panic-timestamp-ops
branch
2 times, most recently
from
8fd5ae6
to
ea3ead4
Compare
This provides a convenient shorthand for the common pattern of reading the timer, adding a small increment, and writing it back. By limiting the range of the interval type, I was able to avoid overflows in realistic scenarios (system uptime < 584 million years), and thus use non-checked arithmetic to eliminate a common panic site. I've gone through and fixed all the code where this was obviously the right thing to use, and left some other code intact if I couldn't convince myself I wouldn't break it. In some cases I've just switched the code to use saturating adds, which are not free (at least for 64-bit integers), but are cheaper than panicking.
cbiffle
force-pushed
the
cbiffle/no-panic-timestamp-ops
branch
from
ea3ead4
to
c849639
Compare
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.
See the commits for more detail, but in brief, this removes a panic from
userlib::hl::sleep_forand then introduces aset_timer_relativeoperation for doing the common timer set operation in a way that won't panic.