[release/8.0] JIT: Disallow mismatched GC-ness for physical promotions #90739
Conversation
![github-actions[bot]](https://github.com/avatars/in/15368?s=60&v=4){kind=small}
Physical promotion was working under the assumption that reinterpreting
GC pointers is undefined behavior, and would happily promote GC pointers
as integers if it saw such accesses. However, physical promotion is
function wide while the UB accesses can be happening in a restricted
(dynamically unreachable) scope. This exact situation happens in
MemoryExtensions.Contains. The issue was uncovered under jit stress
where we did not fold away the guard early enough, meaning that
promotion then saw a `TYP_LONG` access of a `struct { object, int }` and
proceeded to promote it as such.
Fix #90602
dotnet-issue-labeler
bot
added
the
area-CodeGen-coreclr
|
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch Issue DetailsBackport of #90694 to release/8.0 /cc @jakobbotsch Customer ImpactTestingRiskIMPORTANT: If this backport is for a servicing release, please verify that:
|
|
FYI this is going into RC2 (release/8.0). If that's your intention, @jakobbotsch , then I can merge right away, since it has been signed-off and approved by @jeffschwMSFT . If you intended to send it to RC1, please retarget the PR to release/8.0-rc1 and send an email to Tactics requesting approval. |
I think RC2 only is just fine. |
carlossanlop
added
Servicing-consider
ghost
locked as resolved and limited conversation to collaborators
Backport of #90694 to release/8.0
/cc @jakobbotsch
Customer Impact
Code that involves illegal reinterpretations of GC pointers in unreachable code paths can cause the JIT to generate code with incorrect GC reporting, even in the reachable paths.
For example, MemoryMarshal.Contains is a case. When
valueis a GC pointer,RuntimeHelpers.IsBitwiseEquatable<T>()will return false, but under some stress scenarios the JIT will still see the laterUnsafe.As<T, long>(ref value). This can cause it to mistakenly reinterpretvalueas a long without any GC reporting, even outside theRuntimeHelpers.IsBitwiseEquatable<T>()branch.For this particular case, in normal circumstances (no stress modes) the unreachable code is folded away early enough that the JIT does not see the reinterpretation, so no issue happens.
Testing
Verified that the failing test case now generates correct code and GC reporting, even when the stress variables are set.
Risk
Low. Targeted fix with no diffs in any of our own code (under non stress circumstances) that disables physical promotion when the case is detected.