-
Notifications
You must be signed in to change notification settings - Fork 13k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add precondition checks to ptr::offset, ptr::add, ptr::sub #130251
Conversation
This comment has been minimized.
This comment has been minimized.
fe99c6b
to
557d607
Compare
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
…=<try> Add precondition checks to ptr::offset, ptr::add, ptr::sub r? `@ghost`
This comment has been minimized.
This comment has been minimized.
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
Finished benchmarking commit (243a55f): comparison URL. Overall result: ❌ regressions - ACTION NEEDEDBenchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf. Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @bors rollup=never Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)Results (primary -0.2%, secondary -0.3%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResults (primary 1.8%, secondary 2.4%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeResults (primary 0.3%, secondary 0.2%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Bootstrap: 756.901s -> 758.397s (0.20%) |
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
…=<try> Add precondition checks to ptr::offset, ptr::add, ptr::sub r? `@ghost`
This comment has been minimized.
This comment has been minimized.
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
Finished benchmarking commit (2dd09a2): comparison URL. Overall result: ❌✅ regressions and improvements - ACTION NEEDEDBenchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf. Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @bors rollup=never Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)Results (primary 2.7%, secondary -0.6%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResults (primary 1.7%, secondary -0.1%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeResults (primary 0.4%, secondary 0.1%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Bootstrap: 758.82s -> 760.456s (0.22%) |
...because the checks in offset found bugs in a crater run.
ee9b057
to
128ccc3
Compare
Rebased and blessed the mir-opt tests. |
…=Amanieu Add precondition checks to ptr::offset, ptr::add, ptr::sub All of `offset`, `add`, and `sub` (currently) have the trivial preconditions that the offset in bytes must be <= isize::MAX, and the computation of the new address must not wrap. This adds precondition checks for these, and like in slice indexing, we use intrinsics directly to implement unsafe APIs that have explicit checks, because we get a clearer error message that mentions the misused API not an implementation detail. Experimentation indicates these checks have 1-2% compile time overhead, due primarily to adding the checks for `add`. A crater run (rust-lang#130251 (comment)) indicates some people currently have buggy calls to `ptr::offset` that apply a negative offset to a null pointer, but the crater run does not hit the `ptr::add` or `ptr::sub` checks, which seems like an argument for cfg'ing out those checks on account of their overhead.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Once more, with feeling |
|
☀️ Test successful - checks-actions |
Finished benchmarking commit (b8495e5): comparison URL. Overall result: ❌✅ regressions and improvements - please read the text belowOur benchmarks found a performance regression caused by this PR. Next Steps:
@rustbot label: +perf-regression Instruction countThis is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.
Max RSS (memory usage)Results (primary -0.6%, secondary -2.6%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResults (primary -0.9%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeResults (primary -0.2%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Bootstrap: 775.103s -> 774.269s (-0.11%) |
@rustbot label: +perf-regression-triaged Results are net neutral and not significant enough to worry about. Alternatively, the slowdown is justified by finding bugs in real code. |
Rust 1.83 introduces some additional out-of-bound checks [0], making it illegal to attempt to load at an out-of-bound access when trying to load/store values from/to register in rbpf's interpreter, and causing the program to panick even before we reach the safety checks from check_mem(). I understand we need to use wrapping_offset() rather than offset() in that case, which causes the operation itself (but not the resulting poitner) to be safe, and the checked to be deferred. See also the related GitHub issue [1]. [0] rust-lang/rust#130251 [1] #115 Reported-by: Ben Kimock <kimockb@gmail.com> Signed-off-by: Quentin Monnet <qmo@qmon.net>
Rust 1.83 introduces some additional out-of-bound checks [0], making it illegal to attempt to load at an out-of-bound access when trying to load/store values from/to register in rbpf's interpreter, and causing the program to panick even before we reach the safety checks from check_mem(). I understand we need to use wrapping_offset() rather than offset() in that case, which causes the operation itself (but not the resulting poitner) to be safe, and the checked to be deferred. See also the related GitHub issue [1]. [0] rust-lang/rust#130251 [1] #115 Reported-by: Ben Kimock <kimockb@gmail.com> Signed-off-by: Quentin Monnet <qmo@qmon.net>
All of
offset
,add
, andsub
(currently) have the trivial preconditions that the offset in bytes must be <= isize::MAX, and the computation of the new address must not wrap. This adds precondition checks for these, and like in slice indexing, we use intrinsics directly to implement unsafe APIs that have explicit checks, because we get a clearer error message that mentions the misused API not an implementation detail.Experimentation indicates these checks have 1-2% compile time overhead, due primarily to adding the checks for
add
.A crater run (#130251 (comment)) indicates some people currently have buggy calls to
ptr::offset
that apply a negative offset to a null pointer, but the crater run does not hit theptr::add
orptr::sub
checks, which seems like an argument for cfg'ing out those checks on account of their overhead.