5 ms·
As I understand it, the function that used the xdcbt instruction had an oversight that led to the first set of crashes, so it was rewritten to fix that issue. E
by luc157 9y ago
As I understand it, the function that used the xdcbt instruction had an oversight that led to the first set of crashes, so it was rewritten to fix that issue. Even with the fix, the game programmer decided to remove the PREFETCH_EX flag, which is what caused the copy routine to use xdcbt in the first place. So xdcbt ended up in the compiled code, but the flag that caused it to be used wasn't there. The branch predictor ran it anyway, in an unsafe way, leading to the next set of crashes.
- brucedawson 9y agoI think that the developer didn't yet have the fixed version. They thought they would be safe because they weren't passing PREFETCH_EX, but the branch predictor decided otherwise. There were other ways that xdcbt could cause problems (what if the block of memory was freed before being purged from L1) so who knows, and I don't remember for sure.
- xenadu02 9y agoEven if they had the fixed version the branch predictor could still decide to predict the instruction would be hit right? Your ultimate analysis seems correct: the instruction is unsafe to have anywhere.
- syncsynchalt 9y agoIn humans we have a similar problem: https://en.wikipedia.org/wiki/Ironic_process_theory https://en.wikipedia.org/wiki/Ironic_process_theory aka "don't think of a pink elephant"
- Gibbon1 9y agoI'm going to assume that somewhere in the code was something like if(flags | PREFETCH_EX) { xdcbt } else { safe way } And the branch predictor would decide the xdcbt branch was most likely, executes xdcbt and then realizes oops and does it the safe way. Which would be okay except xdcbt is evil, it breaks cache coherency.
- unwind 9y agoNitpick: you meant & for a bitwise AND, of course.
- djhworld 9y agoWow, interesting to see feature flags causing this undesired effect!
- syncsynchalt 9y agoAny if statement could cause this, doesn't have to be feature flags. An untrained branch predictor could still take the "wrong" path even if none of the code that calls that if statement takes the bad path. That's presumably what happened here, the calling program removed all instances of PREFETCH_EX but the CPU would still sometimes execute that branch, such as on the first run through that function. This is a lot like the problem of "don't think of a pink elephant". The mere existence of the "evil opcode" in the library means the CPU might execute it under certain circumstances.
- jonny_eh 9y agoAll clear now, thanks!