-
Notifications
You must be signed in to change notification settings - Fork 12.5k
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
don't inhibit random field reordering on repr(packed(1)) #125360
Conversation
ea7545b
to
1fcce90
Compare
self.flags.intersects(ReprFlags::IS_UNOPTIMISABLE) || self.int.is_some() | ||
} | ||
|
||
/// Returns `true` if this type is valid for reordering and `-Z randomize-layout` | ||
/// was enabled for its declaration crate. | ||
pub fn can_randomize_type_layout(&self) -> bool { | ||
!self.inhibit_struct_field_reordering_opt() | ||
&& self.flags.contains(ReprFlags::RANDOMIZE_LAYOUT) | ||
!self.inhibit_struct_field_reordering() && self.flags.contains(ReprFlags::RANDOMIZE_LAYOUT) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is still a bit silly, the only place where can_randomize_type_layout
is called is effectively inside an if !self.inhibit_struct_field_reordering()
... but I didn't want to do a larger refactoring here, not sure what even would be the better structure.
Note that this does not only affect |
This comment has been minimized.
This comment has been minimized.
1fcce90
to
a53f3ed
Compare
Some changes occurred in src/tools/clippy cc @rust-lang/clippy |
@@ -278,7 +278,7 @@ fn reduce_ty<'tcx>(cx: &LateContext<'tcx>, mut ty: Ty<'tcx>) -> ReducedTy<'tcx> | |||
ty = sized_ty; | |||
continue; | |||
} | |||
if def.repr().inhibit_struct_field_reordering_opt() { | |||
if def.repr().inhibit_struct_field_reordering() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FWIW clippy already used to assume inhibit_struct_field_reordering_opt
means that the field order is guaranteed, which was not the case before this PR.
This comment has been minimized.
This comment has been minimized.
a53f3ed
to
823f5bb
Compare
This comment has been minimized.
This comment has been minimized.
823f5bb
to
f707e61
Compare
This comment has been minimized.
This comment has been minimized.
f707e61
to
37aeb75
Compare
The Miri subtree was changed cc @rust-lang/miri |
@bors r+ |
☀️ Test successful - checks-actions |
Finished benchmarking commit (f2e1a3a): comparison URL. Overall result: ❌✅ regressions and improvements - ACTION NEEDEDNext Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression 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 -4.5%, secondary 2.5%)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.
CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 669.28s -> 667.137s (-0.32%) |
Is this noise 👨 🫴 🦋 (a bunch of them look like the previous PR's results bouncing back to normal. hopefully it will stabilize soon, before weekly triage) |
We seem to have a lot of noise recently (see e.g. these results). But still, the most serious "primary" regressions seem a bit too big to be just noise. Do these crates have to many packed(1) structs that sorting their fields make such a difference...? |
bitmaps is regressing on but cycles are unchanged, so it might be extra |
don't inhibit random field reordering on repr(packed(1)) `inhibit_struct_field_reordering_opt` being false means we exclude this type from random field shuffling. However, `packed(1)` types can still be shuffled! The logic was added in rust-lang#48528 since it's pointless to reorder fields in packed(1) types (there's no padding that could be saved) -- but that shouldn't inhibit `-Zrandomize-layout` (which did not exist at the time). We could add an optimization elsewhere to not bother sorting the fields for `repr(packed)` types, but I don't think that's worth the effort. This *does* change the behavior in that we may now reorder fields of `packed(1)` structs (e.g. if there are niches, we'll try to move them to the start/end, according to `NicheBias`). We were always allowed to do that but so far we didn't. Quoting the [reference](https://doc.rust-lang.org/reference/type-layout.html): > On their own, align and packed do not provide guarantees about the order of fields in the layout of a struct or the layout of an enum variant, although they may be combined with representations (such as C) which do provide such guarantees.
@rustbot label: +perf-regression-triaged |
This broke ICU4X. It's our fault: we assumed So while I wouldn't go as far as to say it's a breaking change, I wonder if this should be done more carefully, perhaps requiring Or even having (The fix for ICU4X is unicode-org/icu4x#5049) |
Some crates getting broken is expected, it also happened the last time we changed field ordering (#102750) which is why i added the relnotes label. Also note that If the beta crater run shows a bigger impact then a more careful approach would make sense. |
Right, but I think in this case, while the nomicon and reference seem to be clear that So while the docs are clear, I wonder if the ecosystem's impression of how things work is going to be a problem for this change. That's not as much the case for I'm also not sure if this will show up much on crater since it may require specific kinds of test failures. |
Fixes #5039 Caused by rust-lang/rust#125360. We were assuming that `packed` meant `C, packed` already. This is an assumption I've seen throughout the Rust ecosystem so there may be reasons to revert.
If this is a common source of confusion, maybe there should be a lint that encourages people to use an explicit representation with |
Fixes unicode-org#5039 Caused by rust-lang/rust#125360. We were assuming that `packed` meant `C, packed` already. This is an assumption I've seen throughout the Rust ecosystem so there may be reasons to revert.
Fixes unicode-org#5039 Caused by rust-lang/rust#125360. We were assuming that `packed` meant `C, packed` already. This is an assumption I've seen throughout the Rust ecosystem so there may be reasons to revert.
The |
Fixes unicode-org#5039 Caused by rust-lang/rust#125360. We were assuming that `packed` meant `C, packed` already. This is an assumption I've seen throughout the Rust ecosystem so there may be reasons to revert.
Fixes unicode-org#5039 Caused by rust-lang/rust#125360. We were assuming that `packed` meant `C, packed` already. This is an assumption I've seen throughout the Rust ecosystem so there may be reasons to revert.
Fixes unicode-org#5039 Caused by rust-lang/rust#125360. We were assuming that `packed` meant `C, packed` already. This is an assumption I've seen throughout the Rust ecosystem so there may be reasons to revert.
This update brings us to zerovec 0.10.4 which addresses a flaw that Dependabot is warning about: > The affected versions make unsafe memory accesses under the > assumption that `#[repr(packed)]` has a guaranteed field order. > > The Rust specification does not guarantee this, and > rust-lang/rust#125360 (1.80.0-beta) starts reordering > fields of `#[repr(packed)]` structs, leading to illegal memory > accesses. > > The patched versions 0.9.7 and 0.10.3 use `#[repr(C, packed)]`, > which guarantees field order.
This update brings us to zerovec 0.10.4 which addresses a flaw that Dependabot is warning about: > The affected versions make unsafe memory accesses under the > assumption that `#[repr(packed)]` has a guaranteed field order. > > The Rust specification does not guarantee this, and > rust-lang/rust#125360 (1.80.0-beta) starts reordering > fields of `#[repr(packed)]` structs, leading to illegal memory > accesses. > > The patched versions 0.9.7 and 0.10.3 use `#[repr(C, packed)]`, > which guarantees field order.
Using #[repr(packed)] alone does not guarantee that the struct fields will stay in the specified order, and as of a change in Rust 1.80, the compiler will actually reorder such structs in practice in some cases: <rust-lang/rust#125360> Add "C" to all structs that were previously #[repr(packed)] alone, since these are all trying to match an externally-defined layout where order matters. None of these would get reordered in practice today, even with the Rust 1.80 change, but this ensures they will always stay consistent. Change-Id: I397fd0bd531a34e0f1726afb830bcd7fcc6a2f05 Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5758933 Commit-Queue: Daniel Verkamp <dverkamp@chromium.org> Reviewed-by: Frederick Mayle <fmayle@google.com>
inhibit_struct_field_reordering_opt
being false means we exclude this type from random field shuffling. However,packed(1)
types can still be shuffled! The logic was added in #48528 since it's pointless to reorder fields in packed(1) types (there's no padding that could be saved) -- but that shouldn't inhibit-Zrandomize-layout
(which did not exist at the time).We could add an optimization elsewhere to not bother sorting the fields for
repr(packed)
types, but I don't think that's worth the effort.This does change the behavior in that we may now reorder fields of
packed(1)
structs (e.g. if there are niches, we'll try to move them to the start/end, according toNicheBias
). We were always allowed to do that but so far we didn't. Quoting the reference: